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About This Manual 



Purpose 

This language reference manual for the NEWP product presents you with information on 
how to use various features of NEWP to do systems programming. NEWP is an ALGOL- 
based language, and this manual indicates the ways in which NEWP features are similar to 
or different from those in ALGOL. 

Scope 

Along with information on the structure and components of NEWP programs, the manual 
provides syntax and explanations for use of declarations, statements, expressions, 
functions, and compiler controls. The manual also gives guidance in using the UNSAFE 
mode. Appendixes provide information on ALGOL features not included in NEWP, 
information on reserved words, and instructions for reading syntax diagrams. 

Audience 

This manual is directed to system software programmers. 

Prerequisites 

You should know the ALGOL language and should be familiar with your system 
architecture. 

How to Use This Manual 

This document contains reference information for each NEWP feature, which can be 
accessed either through the index or the table of contents. Cross references are provided 
within each section. This manual should be used in conjunction with the ALGOL 
Programming Reference Manual, Volume 1: Basic Implementation. 
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Organization 

This manual is divided into eight sections and three appendixes, supplemented by an 
index. 

Section 1. Program Structure 

This section gives a brief introduction to NEWP, discusses the relationship between 
NEWP and ALGOL, and presents the basic structure of a NEWP program. 

Section 2. Language Components 

This section presents the most elemental constructs in the NEWP language. 
Section 3. Declarations 

This section provides information on differences between NEWP and ALGOL declarations. 
It also provides information on declarations that are available only in NEWP. 

Section 4. Statements 

This section provides information on differences between NEWP and ALGOL statements. 
It also provides information on statements that are available only in NEWP. 

Section 5. Expressions and Functions 

This section provides information on differences between NEWP and ALGOL expressions 
and functions. It also provides information on expressions and functions that are available 
only in NEWP. 

Section 6. Compiling NEWP Programs 

Various input and output files used by the NEWP compiler are presented here. 
Section 7. Compiler Controls 

This section provides information on differences between NEWP and ALGOL compiler 
controls. It also provides information on compiler control options that are available only 
in NEWP. 

Section 8. UNSAFE Mode 

The various programming constructs that are considered unsafe for general use are 
presented in this section, as well as some advice on their proper use. 

Appendix A. ALGOL Features Not Implemented in NEWP 

For reference purposes, a list of ALGOL features not provided in NEWP is presented. 

Appendix B. Reserved Words 

A reference list of reserved words and keywords, along with their types, is provided. 
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Appendix C. Understanding Railroad Diagrams 

Information on the specifics of railroad, or syntax, diagrams is provided. 

Related Product Information 

Unless otherwise stated, all documents referred to in this publication are MCP/AS 
documents. The titles have been shortened for increased usability and ease of reading. 

The following documents are included with the software release documentation and 
provide general reference information: 

• The Glossary includes definitions of terms used in this document. 

• The Documentation Road Map is a pictorial representation of the Product 
Information (PI) library. You follow paths through the road map based on tasks you 
want to perform. The paths lead to the documents you need for those tasks. The Road 
Map is available on paper and on the PI Library CD-ROM. If you know what you want 
to do, but don't know where to find the information, start with the Documentation 
Road Map. 

• The Information Availability List (IAL) lists all user documents, online help, and 
HTML files in the library. The list is sorted by title and by part number. 

The following documents provide information that is directly related to the primary 
subject of this publication. 

ALGOL Programming Reference Manual, Volume 1: Basic Implementation 

This manual describes the basic features of the Extended ALGOL programming language. 
This manual is written for programmers who are familiar with programming concepts. 

Work Flow Language (WFL) Programming Reference Manual 

This manual presents the complete syntax and semantics of the Work Flow Language 
(WFL). This language is used to construct jobs that compile or run programs written in 
other languages, and is used to construct jobs that perform library maintenance such as 
copying files. This manual is written for individuals who have some experience with 
programming in a block-structure language such as ALGOL and who know how to create 
and edit files using CANDE or the Editor. 
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Section 1 
Program 



Structure 



Introduction 



to NEWP 



NEWP is considered an internal language product and, as such, is not governed by the 
same migration and deimplementation rules as other language products. 

NEWP is a language based on ALGOL and is designed for your use in implementing system 
software. Its major application is the Master Control Program (MCP). As a result, some 
features of NEWP are closely tied to the features available in the MCP and the underlying 
hardware. From time to time, in an effort to provide improved features in the our software 
system, NEWP requires changes that are incompatible with previous versions. Every effort 
is made to avoid incompatible changes, but at times they are unavoidable. Unisys 
recommends that you evaluate all NEWP programs for compatibility with the compiler 
and the system on each release. 

The code files produced by the compiler are executable unless you use unsafe features. 
For more information on unsafe features, see Section 8, "UNSAFE Mode." 

Although NEWP is based on ALGOL, there are some significant differences between the 
two languages. One major difference is that NEWP performs more rigorous type checking 
than ALGOL does, which helps prevent errors caused by unexpected type conflicts. 

As a result, a program that compiles with the ALGOL compiler sometimes receives syntax 
errors from the NEWP compiler. For example, ALGOL allows a REAL variable to be 
passed to an INTEGER by-reference formal parameter and allows this formal parameter to 
be passed to a REAL variable. NEWP does not allow either, unless the actual parameter 
has had its type explicitly converted with a type transfer function. 

Another difference is that NEWP provides a number of features that ALGOL lacks, such as 
modules, user-defined scalar types, and sets. 

NEWP does not provide all the features of ALGOL, nor does NEWP include the 
environmental software interfaces that ALGOL supports, such as interfaces to Data 
Management System II (DMSII), Communications Management System (COMS), and 
Semantic Information Manager (SIM). 
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Program Structure 



Because the syntax and semantics of most NEWP constructs are the same as the syntax 
and semantics of the corresponding ALGOL constructs, only those features of NEWP that 
are not the same as in ALGOL are described in this manual. Elements of NEWP that are 
not outlined in this document are identical in operation to ALGOL as described in the 
ALGOL Programming Reference Manual, Volume 1: Basic Implementation. Specific 
information on ALGOL features not supported in NEWP can be found in Appendix A, 
"ALGOL Features Not Implemented in NEWP." 



Program Unit 



A program unit is a group of NEWP constructs that can be compiled as a whole. The 
following diagram shows the elements that you can include in a NEWP program. 

<program unit> 



level 2 procedure heading>- 



i ng>-l 



BEGIN 



<declaration> — ; 



-<module decl aration>- 
END — . 



<statement>- 



<level 2 procedure heading> 

=level 2 procedure type> 



I p PROCEDURE — procedure heading>- 

I— <level 2 Drocedure tvDe>— ' 



t- BOOLEAN -r 

- DOUBLE — 

- INTEGER - 
L- REAL 1 
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Elements of a NEWP Program 

The simplest valid NEWP program is just a BEGIN/END pair. The BEGIN/END pair can 
enclose a list of declarations, a list of modules, or a list of statements. If the BEGIN/END 
pair is preceded by a procedure heading, the entire program is a procedure, which can be 
typed or untyped and can have one or more parameters. 

A NEWP program cannot include the global part or separate procedure list that are valid 
in ALGOL. 

In NEWP, the lexical level is increased only by nested procedures, not by both nested 
procedures and nested blocks, as in ALGOL. Thus, by default, any nested procedure 
causes a change in lexical level, while a nested block that is not a procedure does not. 

Segmentation is based upon lexical levels. By default, a new segment is assigned to each 
procedure declared at lexical level 15 or below, whether or not you declare local variables. 
You can change the lexical level at which segmentation occurs by using the 
SEGMENTLEVEL block directive. In addition, you can override automatic segmentation 
on a block-by-block basis by using the SEGMENT block directive. 

For the semantics of the <procedure heading>, see "PROCEDURE Declaration" in 
Section 3, "Declarations." For information on block directives, see "Block Directives" in 
Section 7, "Compiler Controls." 
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Section 2 

Language Components 



Language components are the building blocks of NEWP. These components consist of 
basic symbols, reserved words, and constants. 

Basic Symbols 

Basic symbols are the same in NEWP as in ALGOL, except that both uppercase and 
lowercase letters are allowed in NEWP. Compiler control options and any token in a 
program can be written in lowercase letters. Any mixture of uppercase and lowercase is 
legal; the NEWP program does not make a distinction between uppercase and lowercase 
letters. 

Reserved Words 

Reserved words are described and listed in Appendix B, "Reserved Words." 

Numbers, Numeric Constants, and String Constants 

In ALGOL, there is a syntactic ambiguity between string constants and numeric constants. 
For example, the following ALGOL symbols could be interpreted as the 8-bit character A 
when you use the symbols in a string concatenation or as the 48-bit operand represented 
by the 12 hexadecimal characters 0000000000C1 when you use the symbols in an 
arithmetic expression: 

8"A" 

In NEWP, string constants and numeric constants are syntactically distinct; string 
constants are delimited by quotation mark characters ("), and numeric constants are 
delimited by apostrophe characters (')• 

The following is information on NEWP numbers, numeric constants, and string constants. 
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Numbers 

<number> 



1— <unsigned number>- 

— <sign>— I 

— <numeric constant> 

— <constant identifier^ 



Explanation 

NEWP extends the definition of a <number> to include <numeric constant> and <constant 
identifier>. For more information, refer to "Numeric Constants" in this section and to the 
"CONSTANT Declaration" in Section 3, "Declarations." 



Numeric Constants 

<numeric constant> 



t-<EBCDIC constant> r 

— <ASCII constant> 

— <BCL constant> 

— <hexadecimal constant>— 

— <octal constant> 

— quaternary constant> — 
— <binary constant> 



<EBCDIC constant> 



-/6\— r— <EBCDIC numeric character>- 

8 — I L " 

80 - 1 



<EBCDIC numeric character> 

Any EBCDIC character except an apostrophe ('). 

<ASCII constant> 

r< 

— i— 7 — i— ' — 1 — /6\ — I — <ASCI I numeric character>- 
1—70—1 L_ 1 1 



<ASCII numeric character> 

Any ASCII character except an apostrophe (')• 
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Language Components 



<BCL constant> 




BCL 



numeric character>- 



- 6 — L_ " 1 

L- 60 — 1 

<BCL numeric character> 

Any BCL character except an apostrophe ('). 

Note: The BCL data type is not supported on all systems. 
<hexadecimal constant> 

— i— 4 — i— 1 — I— /12\-<hexadecimal character>— L- 1 

L- 40 - 1 

<octal constant> 

— ,- 3 — ,- 1 -t/16\-<octal character>-L 1 

L- 30 - 1 

<octal character> 

Any digit from 0 through 7. 

<quaternary constant> 

— |— 2 — |— 1 — I— /24\-<quaternary character>— L 1 

L 20 - 1 

<quaternary character> 

— r 0 n 

- l - 

- 2 - 
L- 3 - 1 

<binary constant> 

— i— 1 — |— 1 — t/48\-<binary character>— L 1 

I— 10 — ' 
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<binary character> 



Explanation 

A numeric constant is a representation of a 48-bit value. You can specify the value in 
EBCDIC, ASCII, BCL, hexadecimal, octal, quaternary, or binary notation. An apostrophe (') 
in a BCL, EBCDIC or ASCII numeric constant is represented by two adjacent apostrophe 
characters. For example, the following constant is the EBCDIC numeric constant 
consisting of a single apostrophe character: 



A character code that ends in zero (that is, 10, 20, 30, 40, 60, 70, or 80) indicates that the 
bits represented by the constant are to be left-justified within the 48-bit arithmetic value, 
with binary-zero fill. All other character codes generate right-justified, binary-zero-filled 
values. 



<string constant> 



t — <EBCDIC string constant> r 

— <ASCII string constant> 

— <hexadecimal string constant>— 
— <BCL string constant> 



<EBCDIC string constant> 



■< <space>- 



■ i i i 



String Constants 



1 ,- " — 1 — r-<EBCDIC string character>- 

_ 8 — ' I 11 



— 48 — " — I— <hexadecimal character> — <hexadecimal character>— L- " — 



<EBCDIC string character> 



Any EBCDIC character except a quotation mark ("). 



<ASCII string constant> 



■<space>- 



7 — 



ll 



-<ASCII string character>- 



ii 



l_ 47 _ 



II 
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<ASCII string character> 

Any ASCII character except a quotation mark ("). 

<hexadecimal string constant> 

■< <space> 

4 — " — t<hex character^— " —I 1 

<hexadecimal character> 

Any digit from 0 through 9 or any letter from A through F. 
<BCL string constant> 

■< <space> 

1- 6 — " -t<BCL character>-L " J 1 

— 36 — " — I— <octal character* — <octal character>— L- 11 — 

<BCL character> 

Any BCL character except a quotation mark ("). 

<octal character> 

Any digit from 0 through 7. 

Explanation 

String constants are primaries of type string and of subtype EBCDIC, ASCII, hexadecimal, 
or BCL. A string constant of a particular subtype must include only characters defined for 
that subtype. Quotation mark (") characters can be included in strings if you represent 
each embedded quotation mark as two adjacent quotation marks in the syntax. 

No more than 256 characters can appear between one pair of quotation marks in a string 
constant; however, as many as 4095 characters can appear in an EBCDIC string constant, 
ASCII string constant, or hexadecimal string constant. A BCL string constant can contain 
no more than 16 characters. 

You can concatenate string constants by using implicit string concatenation or by using 
the <string concatenation operator> (see "String Expressions" in Section 5, "Expressions 
and Functions"). You can type-transfer a string constant to an arithmetic value by using 
the REAL function. Table 2-1 shows differences in character representation between 
NEWP and ALGOL. 
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Table 2-1. Character Representation: Differences between ALGOL and NEWP 



Actual String 


NEWP Representation 


ALGOL Representation 


ABC 


"ABC" 


"ABC" 


A"B 


"A""B" 


"A B" 








null string 


not implemented 


EMPTY 



Examples of legal string constants include the following: 



"ABCD" 
48"0109" 

48"0109" "ERROR MESSAGE" 
8"A MESSAGE OF TEXT" 
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NEWP provides several kinds of declarations that are not supported by ALGOL. The 
NEWP-specific forms of declarations are discussed in this section and in the "Declarations 
(UNSAFE)" portion of Section 8, "UNSAFE Mode." 

The following table describes the differences between declarations that are supported in 
both NEWP and ALGOL. The table also refers you to more detailed information on 
differences in particular declarations. In addition, information about ALGOL declarations 
that NEWP does not support can be found in Appendix A, "ALGOL Features Not 
Implemented in NEWP." 

Declaration NEWP Information 

ACTIVATION Refer to "ACTIVATION Structure Block Reference 



Variables" later in this section. 



ARRAY 



Refer to "ARRAY Declaration" and "INTERLOCK 
and INTERLOCK ARRAY Declarations" later in 



this section and to "SAVE ARRAY Declaration" in 
Section 8, "UNSAFE Mode." 



ARRAY REFERENCE 



Refer to "ARRAY REFERENCE Declaration" later 
in this section. 



BOOLEAN 



The OWN clause is not supported; use globally 
declared variables instead. 



CONNECTION BLOCK 



Refer to "CONNECTION BLOCK TYPE 
Declaration" under "STRUCTURE TYPE 
Declarations" later in this section. 



DIRECT ARRAY 



The OWN clause is not supported; use globally 
declared variables instead. 



DOUBLE 



The OWN clause is not supported; use globally 
declared variables instead. 



EPILOG PROCEDURE 



Refer to "EPILOG PROCEDURE Declaration" later 
in this section. 
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Declaration 

EXCEPTION PROCEDURE 



NEWP Information 

Refer to "EXCEPTION PROCEDURE Declaration" 
later in this section. 



EXPORT 



Refer to "EXPORT Declaration" later in this 
section. 



IMPORTED 



INTEGER 



The only <data type> supported in the IMPORTED 
declaration is the EVENT data type. 

The OWN clause is not supported; use globally 
declared variables instead. 



LIBRARY 



Refer to "LIBRARY Declaration" later in this 
section. 



OUTPUTMESSAGE ARRAY 



Refer to "OUTPUTMESSAGE ARRAY Declaration" 
later in this section. 



PENDING PROCEDURE 



Refer to "PENDING PROCEDURE ACTUAL 
Declaration" later in this section. 



POINTER 



The OWN clause is not supported; use a globally 
declared variable instead. For information on 
other differences, refer to "POINTER Declaration" 
later in this section. 



PROCEDURE 



Refer to "PROCEDURE Declaration" later in this 
section and in Section 8, "UNSAFE Mode." 



PROCEDURE REFERENCE 
ARRAY 

PROLOG PROCEDURE 



Only the <local procedure reference array 
declaration> form is supported in NEWP. 

Refer to "PROLOG PROCEDURE Declaration" 
later in this section. 



REAL 



The OWN clause is not supported; use a globally 
declared variable instead. 



SIMPLE VARIABLE 



Refer to "SIMPLE VARIABLE Declaration" later in 
this section. 



STRUCTURE BLOCK 



Refer to "STRUCTURE BLOCK TYPE Declaration" 
under "STRUCTURE TYPE Declarations" later in 
this section. 



TRANSLATETABLE 



The <translate table identifier form of the 
<translation specifier> is not supported. 
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Declaration NEWP Information 

VALUE ARRAY Refer to "VALUE ARRAY Declaration" later in this 

section. 

WITH Refer to "WITH Declaration" later in this section. 



ACTIVATION Structure Block Reference Variables 

<activation declaration 

— i— <typed activation decl aration> . 1 

I— <untyped activation declaration^ 

<typed activation declaration 

— ACTIVATION — OF — i— <structure block type identifier — ■— <identi fier list> — | 
^connection block type identifier^ 

<untyped activation declaration> 



— ACTIVATION — identifier list>- 
<identifier list> 



r ' i 

— >— <i denti f i er>— 1 1 

Explanation 

A typed ACTIVATION structure block reference declares an activation variable with the 
same type as the specified structure block type identifier. If no structure block type is 
specified, then the variable is considered untyped and the UNSAFE MISC directive is 
required. 

An activation variable is used to contain the skeleton SIRW found at index 1 within the 
structure block. The compiler expects a skeleton SIRW to be provided in the cell given by 
the <activation identifier>. The ACTIVATION structure block reference assignment 
statement is used to obtain the skeleton SIRW for a given instance. 

A reference to an embedded structure block or connection block is permitted using 

outertype . embeddedtype 

Activations are used primarily to control when structure block s become activated, 
especially when the WITH declaration is used in the outer block of the MCP. 

Only typed activation variables can be used to qualify structure block items. 
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The initial value for an activation variable is all zeroes with a TAG of 6. If an activation 
variable is referenced while it is uninitialized, an INVALID OPERAND fault occurs. 

Example 

The following example shows the declarations of an ACTIVATION structure block 
reference variable: 

TYPE SBT = STRUCTURE BLOCK 
BEGIN 
REAL R; 

DEFINE X = 5 #; 
END; 

SBT SBVAR; %Structure Block Variable 

SBT REFERENCE SBREF; %Structure Block Reference Variable 

ACTIVATION OF SBT ASSIRW; %Typed Activation 

ACTIVATION NOTYPE; %Untyped Activation 

ASSIRW := ACTIVATION(SBVAR) ; 
ASSIRW. R := 10; 
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ARRAY Declaration 

<array declaration> 



-, 1 — I ARRAY 

L LONG - 1 L- <array c lasss-l 



r< . ; 1 

L <array identifiers— I— [ — <dimension specs> — ] 



<array class> 

-<type>- 



-y— -typt^ r 

^character type>— 1 



<type> 



BOOLEAN 



DESCRIPTOR 

DOUBLE 

- INTEGER 

- REAL 

<type identifiers 

' — WORD 



<dimension specs> 



Si 



-/15\ , 

-<bound pair>- 



E^UUUIIU [Jell I ^ r 
<type identifiers— ' 



<bound pair> 

— <lower bound> — : — <upper bound>- 



<lower bound> 



-r-<arithmetic expressions — r 
L- <scalar type expressions— I 



<upper bound> 



-^arithmetic expressions — ,- 
L-<scalar type expressions— I 



(All other syntax is identical to ALGOL.) 
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Explanation 

NEWP allows one or all dimensions of an array to be unspecified. The <bound pair> 0.-1 
indicates an unspecified bound (for example, ARRAY A [ 0:-l /). Except for this special 
case, the lower bound can never exceed the upper bound. 

For a one-dimensional array, the unspecified bounds indication causes the compiler to 
build a zero-length descriptor for the array. For a multidimensional array, if any bounds 
are unspecified, either all bounds or only the last bound must be unspecified. If all bounds 
are unspecified, a zero-length descriptor is built. If only the last bound is unspecified, the 
dope vectors for the array are built normally and only the row descriptors are built as 
zero-length descriptors. 

For a multidimensional array, a zero-length descriptor has to be used under the UNSAFE 
(DESCRIPTOR) construct. 

If a dimension is specified by a <type identifier>, the type of the dimension is defined to 
be that of type identifier. The type identifier must denote an ordered, bounded, discrete 
type. The lower bound of this dimension is taken from the smallest value defined for that 
type (the .LBOUND value), and the upper bound is taken from the largest value defined 
(the .UBOUND value). When an array is referenced, a subscript that corresponds to a 
scalar type dimension must be of the same type as the dimension. 

If a dimension is declared by a <bound pair>, then the <lower bound> and the <upper 
bound> must be either both arithmetic expressions or both scalar type expressions. 

If both bounds are given by <scalar type expressions, the expressions must be of the 
same ordered type. The type of the dimension is defined to be that of the <scalar type 
expressions. 

For more information on ARRAY declarations, see "INTERLOCK and INTERLOCK ARRAY 
Declarations" and the discussion of <type identifier in "SCALAR TYPE Declaration" later 
in this section. Also see "DESCRIPTOR [DESCRIPTOR]" and "WORD [WORD]" in 
Section 8, "UNSAFE Mode." 
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ARRAY REFERENCE Declaration 



<array reference declaration> 



L DIRECT -I L <array c i ass 



ARRAY — REFERENCE 



<array reference identifier— 1 — [ — <lower bounds> — ] 



<array reference identifier> 

— <i denti f i er> 



<lower bounds> 



-<lower bound>- 



Explanation 

The ARRAY REFERENCE declaration in NEWP has the same syntax and semantics as the 
ARRAY REFERENCE declaration in ALGOL, except that in NEWP, array references can 
be declared to have scalar types. 

In addition, each dimension of a NEWP array reference can be specified to have a scalar 
type. The scalar type must be an ordered, bounded discrete type. If the lower bound of a 
dimension is defined by a <scalar type expression;*, the type of the dimension is the type 
of the expression. When an array reference is used, a subscript that corresponds to a 
scalar type dimension must be of the same type as was used in the declaration for that 
dimension. 

For more information on scalar types, see "SCALAR TYPE Declaration" later in this 
section and "Scalar Type Expressions" in Section 5, "Expressions and Functions." 
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CONNECTION BLOCK TYPE Declaration 



<connection block type declaration> 



— TYPE — <identifier>— = — CONNECTION BLOCK 

END -I ' 



~^ I FORWARD 

L- BEGIN — <declaration list> 



Connection blocks are similar to structure blocks but they provide the means to specify 
procedures for export and import. From the CONNECTION BLOCK TYPE declaration, you 
can declare a connection library. Connection libraries provide the ability to establish 
asynchronous two-way connections that provide access to each other's procedures. Refer 
to the ALGOL Programming Reference Manual, Volume 1 for details regarding 
connection libraries. 



CONSTANT Declaration 

<constant declaration> 



DOUBLE 

DESCRIPTOR 

- INTEGER — 

- REAL 



-<type identifier^ 
- WORD 



CONSTANT 



constant identifier^ 



17 



-<constant value> 



IT 



<constant identifier> 



=identifier>- 



<constant value> 



constant arithmetic expression> — r- 
constant scalar type expression^ 



Explanation 

The CONSTANT declaration can be used to declare arithmetic or enumerated constants. 
This declaration is particularly useful for declaring a series of INTEGER constants where 
each value is to be one greater than the previous value. If no type is provided in the 
<constant declaration>, REAL is assumed. 
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The declaration and use of WORD and DESCRIPTOR constants do not require the use of 
the UNSAFE WORD or DESCRIPTOR block directives because constants are treated as 
literals. 



If a <constant identifier appears with a <constant value>, the identifier is associated with 
the specified value. If no constant value is given, the compiler assigns the identifier a value 
one greater than the value of the previous identifier. The compiler assigns the value 0 
(zero) to the identifier if it is the first identifier in the list. If the type of a CONSTANT 
declaration is an enumerated type identifier, or a subtype of one, any constant value must 
be a <constant scalar type expressions All other types of CONSTANT declarations can 
use only a <constant arithmetic expression> as the constant value. 

The constant value is evaluated in the context of the CONSTANT declaration (unlike 
defines, for which the text is expanded in the context of the invocation). 

If the type identifier is a subtype, it must be a descendant type of INTEGER or an 
enumerated type. Each constant scalar type expression must be of the same type as the 
type identifier. If the type identifier is a bounded type, the constant value assigned to the 
< constant identifier is checked to verify that the value falls within the valid range for the 
type. 

Examples 



CONSTANT 



TASKMSCW, 


% 


AUTOMATICALLY ASSIGNED 


TASKPARAMS, 


% 


1 


CODEHEADERINDEX = 0, 


% 


STARTS AGAIN AT 0 


RUNNINGCOUNT, 


% 


1 


CODELINKS, 


% 


2 


MARKER = CODELINKS, 


% 


2 ALSO 


C0MPILERINF0, 


% 


3 


TOFFSET = MARKER+5, 


% 


7 


NEXTWORD; 


% 


8 



TYPE SUBCLASS = SUBTYPE INTEGER 0..63; 
SUBCLASS CONSTANT 
UNSPECIFIED = 0, 



BY_VALUE, % 1 

BY_NAME, % 2 

BY_REFERENCE, % 3 

EXTERNAL_PR0C, % 4 

F0RWARD_PR0C, % 5 

LIBRARY_PR0C, % 6 

INLINE_PR0C, % 7 

ORDINARY PROC; % 8 



TYPE COLOR = (RED, GREEN, BLUE, YELLOW) ; 
COLOR CONSTANT 

MYFAVORITE = BLUE, 

YOURFAVORITE = RED, 

SCREENCOLOR = GREEN; 
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EPILOG PROCEDURE Declaration 

<epilog procedure declaration> 

— EPILOG PROCEDURE — <epilog procedure identifier— ; > 

->-<compound statement> 1 

<epilog procedure identifier> 

— <i denti f i er> 1 

Explanation 

The EPILOG PROCEDURE declaration in NEWP is similar to the EPILOG PROCEDURE 
declaration in ALGOL except for the following differences. 

The following restrictions apply to epilog procedures: 

• The body of an epilog procedure can contain a <compound statement> only. The 
epilog procedure body cannot be NULL. 

• The INLINE block directive cannot be used for an epilog procedure. If this block 
directive is used, a syntax error is issued. 

• Epilog procedures can be exported from modules by declaring them as FORWARD in 
the <module head>, exactly as in any other procedure. When the epilog procedure is 
imported, it acts like any other untyped procedure; an abnormal exit in the importing 
module does not cause the MCP to invoke the epilog procedure automatically. 
Automatic invocation can occur only in the block in which the epilog procedure is 
originally declared. 

• If the MCP option is set, the epilog procedure cannot be declared in such a way that 
its Program Control Word (PCW) is placed in the segment dictionary, since this block 
is never exited. This means that an epilog procedure cannot be declared in the outer 
block (lexical level 0) of the MCP. 

When the MCP option is not set, an epilog procedure in the outer block is permitted. 

• An epilog procedure cannot be address equated. 
Considerations for Use 

One stack cell is saved if the epilog procedure has no FORWARD declaration and is 
declared as the last item in the block. This is because the epilog procedure Program 
Control Word (PCW) must be directly below the Software Control Word (SCW) for the 
block, and the compiler generates a second PCW, when necessary, to ensure this ordering. 
The use of duplicate PCWs is a concern only in an environment in which the conservation 
of stack cells is important. 
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EXCEPTION PROCEDURE Declaration 

<exception procedure declaration> 

— EXCEPTION PROCEDURE — exception procedure identifier— ; > 

->-<compound statement> 1 

<exception procedure identiller> 

— <i denti f i er> 1 

Explanation 

The EXCEPTION PROCEDURE declaration in NEWP is similar to the EXCEPTION 
PROCEDURE declaration in ALGOL except for the following differences. 

Usually, an exception procedure is subject to interrupts, including a DS system command. 
However, you can use the PROTECTED block directive with exception procedures for 
which an interruption is not acceptable. For more information on the PROTECTED block 
directive, see "PROTECTED" in Section 7, "Compiler Controls." 

The following restrictions apply to exception procedures: 

• The body of an exception procedure can contain a <compound statement> only. The 
exception procedure body cannot be NULL. 

• The INLINE block directive cannot be used for an exception procedure. If this block 
directive is used, a syntax error is issued. 

• Exception procedures can be exported from modules by declaring them as FORWARD 
in the <module head>, exactly as in any other procedure. When the exception 
procedure is imported, it acts like any other untyped procedure; an abnormal exit in 
the importing module does not cause the MCP to invoke the exception procedure 
automatically. Automatic invocation can occur only in the block in which the 
exception procedure is originally declared. 

• If the MCP option is set, the exception procedure cannot be declared in such a way 
that its Program Control Word (PCW) is placed in the segment dictionary, since this 
block is never exited. This means that an exception procedure cannot be declared in 
the outer block (lexical level 0) of the MCP. 

When the MCP option is not set, an exception procedure in the outer block is 
permitted. 

• An exception procedure cannot be address equated. 
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Considerations for Use 

One stack cell is saved if the exception procedure has no FORWARD declaration and is 
declared as the last item in the block. This is because the exception procedure Program 
Control Word (PCW) must be directly below the Software Control Word (SCW) for the 
block, and the compiler generates a second PCW, when necessary, to ensure this ordering. 
The use of duplicate PCWs is a concern only in an environment in which the conservation 
of stack cells is important. 

EXCEPTION PROCEDURE FORWARD Declaration 

<exception procedure forward declaration> 

— EXCEPTION PROCEDURE — exception procedure identifier— FORWARD 1 

Explanation 

An exception procedure can be declared forward in the same manner as in other 
procedures. If an <exception procedure forward declaration> exists, then references to 
the procedure can occur before the EXCEPTION PROCEDURE declaration. 
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EXPORT Declaration 

<export declaration> 

— EXPORT 



L [ — PROTECTED -■ p ] -I 

I— <linkage class>— ' 



■»— <export object specification>- 
<linkage class> 

— <i nteger> 



L<export options>— ' 



<export object specification 

^procedure identifier 



— <array identifier>- 

-<file identifier 

-<procedure reference identifier>- 
-<event identifier 



-<event array identifier>- 



L AS — <EBCDIC string literal^ 
<export options> 

— ( — LINKCLASS — = -r- PROTECTED r- 

I— <linkage class>— ' 



Explanation 

The EXPORT declaration in NEWP is similar to the EXPORT declaration in ALGOL, 
except that NEWP allows different export objects, and the LINKCLASS can be provided in 
two ways. If the linkage class for all objects exported in the EXPORT declaration is the 
same, the linkage class can be specified just after EXPORT; it then applies to the entire list 
of objects. If the objects in the export list have different linkage classes they can be 
specified individually after each <export object specification>. 



The <linkage class> is an integer between 0 and 15. A library entry point can be exported 
with protection by including the PROTECTED clause in the EXPORT declaration for that 
entry point. Only programs belonging to appropriate linkage classes can be linked to a 
protected entry point. The linkage classes are defined in a table maintained by MCP 
LIBRARIAN. If the PROTECTED clause is not included, the linkage class is 0 (zero). 

There are 16 linkage classes ranging from 0 to 15. Classes 0 and 1 are used by the MCP 
such that tasks of linkage class 0 can link only to objects of linkage class 0 and tasks of 
linkage class 1 are allowed to link to objects of any linkage class. The remaining classes 
are reserved for use by systems software. 
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Although, from the export side, procedure reference identifiers can be included in the 
EXPORT declaration, from the calling side the object must be declared as if it were a 
normal procedure. Only the exporting side can make assignments to the procedure 
reference identifier. 

EXPORT declarations are not allowed within module alternatives. 

In-line procedures, procedures that are declared to have a scalar type, and procedures 
with scalar type parameters cannot appear in an EXPORT declaration. 

Note: The keyword EXPORT is interpreted as a module <export list> when it appears 
in the module head of a MODULE declaration (old). EXPORT in any other 
context is interpreted as a library <export declaration>. 

For information related to the EXPORT declaration, see "LIBRARY Declaration," 
"MODULE Declaration (Old)," and "In-Line Procedures" later in this section. 

Examples 

EXPORT MYPROG; 

EXPORT [PROTECTED] YOURPROC, THEIRPROC; 

EXPORT [PROTECTED 1] OURPROC; 

EXPORT THEPROC (LINKCLASS = 2), 
APROC (LINKCLASS = 6); 
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INTRINSIC Declaration 

<intrinsic declaration> 

— INTRINSIC -L<i intrinsic identifier^ . J 1 

I— <equation part>— ' 

Explanation 

INTRINSIC declarations are provided especially for use in the MCP, where implicit 
references to MCP addresses can cause problems. The compiler is directed to use the 
address associated with the INTRINSIC declaration in place of a newly allocated cell in 
the segment dictionary (normal program) or to use a direct reference to the global 
environment within the MCP. 

Each intrinsic declared is assigned a stack cell. If you do not use an addressequation, the 
cell is stored in the segment dictionary and contains an appropriate intrinsic binding word. 
If you supply an address through address equation, that address is used for references and 
no initialization is done by the compiler. The <equation part> is an UNSAFE construct; see 
"Address Equation" in Section 8, "UNSAFE Mode," before proceeding. 

INTRINSIC declarations are associated by name to the references made by the compiler 
for implicitly called MCP intrinsics. When the compiler generates code to refer to an MCP 
intrinsic, it looks for a specified identifier, derived from the intrinsic name in the scope of 
the code being compiled. A list of these recognized intrinsic identifiers is shown in Table 
3-1. 

If the identifier is found and is of type INTRINSIC, the compiler uses the address 
associated with the identifier. If no useable intrinsic is found, an intrinsic binding word is 
allocated in the segment dictionary. 

Table 3-1 shows the recognized intrinsic identifiers, along with associated MCP identifiers 
and MCP intrinsic numbers, in hexadecimal form. 



Table 3-1. Intrinsic Identifiers 



Intrinsic Identifier 


MCP Identifier 


Number 


INTRINSIC_STACKVECTOR 


STACKVECTOR 


02 


INTRINSIC_MEMORY 


MEMORY 


04 


INTRINSIC_ARRAYDEC 


ARRAYDEC 


07 


INTRINSIC_BLOCKEXIT 


BLOCKEXIT 


OA 


INTRINSIC_BADGOTO 


G0T0S0LVER 


OB 


INTRINSICJNTRINSICINFO 


INTRINSICINFO 


11 


INTRINSIC_MYJOB 


MYJOB 


12 



8600 2003-403 



3-15 



Declarations 



Table 3-1. Intrinsic Identifiers 



Intrinsic Identifier 


MCP Identifier 


Number 


INTRINSIC_STRUCTURE_FREEZER 


STRUCTURE_FREEZER 


15 


INTRINSIC_FREEZELIBRARY 


FREEZELIBRARY 


16 


INTRINSIC_PROGRAMDUMP 


PROGRAMDUMP 


17 


INTRINSIC_TIME 


TIMEINTRINSIC 


18 


INTRINSIC_CLOSE 


CLOSE 


IB 


INTRINSIC_POTL 


POTL 


23 


INTRINSIC_POTC 


POTC 


24 


INTRINSIC_POTH 


POTH 


25 


INTRINSIC_ATTRIBUTEGRABBER 


ATTRIBUTEGRABBER 


29 


INTRINSIC_TRUTHSETS 


TRUTHSETS 


26 


INTRINSIC_ATTRIBUTEHANDLER 


ATTRIBUTEHANDLER 


2A 


INTRINSIC_USERIOERROR 


USERIOERROR 


2E 


INTRINSIC_LOADCONTROL 


LOADCONTROL 


32 


INTRINSIC_SET_GET_LIBRARYSTATUS 


SET_GET_LIBRARYSTATUS 


36 


INTRINSIC_SORT 


SORT 


45 


INTRINSIC_RESIZEANDDEALLOCATE 


RESIZEANDDEALLOCATE 


46 


INTRINSIC_CANCELLIBRARY 


CANCELLIBRARY 


4C 


INTRINSIC_OPENP 


OPENP 


4E 


INTRINSIC_DELIVERY 


DELIVERY 


5D 


INTRINSIC_DESCRIPTORSIZE 


DESCRIPTORSIZE 


5E 


INTRINSIC_LINKLIBRARY 


LINKLIBRARY 


63 


INTRINSIC_EBCTOHEX 


EBCTOHEX 


65 


INTRINSIC_UNRAVEL 


UNRAVEL 


66 


INTRINSIC_MUTATE 


MUTATE 


67 


INTRINSIC_MYSELFER 


MYSELFER 


68 


INTRINSIC_CONTINUER 


CONTINUER 


69 


INTRINSIC_CLOSEP 


CLOSEP 


70 


INTRINSIC_FORKCONTROLCARD 


FORKCONTROLCARD 


76 


INTRINSIC_FIXHANDLER 


FIXHANDLER 


8E 


INTRINSIC_DIRECTOR 


DIRECTOR 


95 


INTRINSIC_CAUSEP 


CAUSEP 


96 
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Intrinsic Identifier 


MCP Identifier 


Number 


INTRINSIC_SETORRESET 


SETORRESET 


99 


INTRINSIC_PROCUREP 


PROCUREP 


9A 


INTRINSICJJBERATEP 


LIBERATEP 


9C 


INTRINSIC_COMBINEPPBS 


COMBINEPPBS 


AB 


INTRINSIC_FORKHANDLER 


FORKHANDLER 


AF 


INTRINSIC_EBCTOASC 


EBCTOASC 


Bl 


INTRINSIC_ASCTOHEX 


ASCTOHEX 


B2 


INTRINSIC_ASCTOEBC 


ASCTOEBC 


B4 


INTRINSICJHEXTOEBCDIC 


HEXTOEBCDIC 


BD 


INTRINSIC_HEXTOASCII 


HEXTOASCII 


BE 


INTRINSIC_READLOCKTIMEOUT 


READLOCKTIMEOUT 


C2 


INTRINSIC_CLOCKOFFPCW 


CLOCKOFFPCW 


C3 


INTRINSIC_CLOCKONPCW 


CLOCKONPCW 


C4 


INTRINSIC_CLOCKRESUMEPCW 


CLOCKRESUMEPCW 


C5 


INTRINSIC_CLOCKSUSPENDPCW 


CLOCKSUSPENDPCW 


C6 


INTRINSIC_GETSTRINGAREA 


GETSTRINGAREA 


C9 


INTRINSIC_GETSTRINGPOOLSIZE 


GETSTRINGPOOLSIZE 


cc 


INTRINSIC_RESETSTRINGPOOLSIZE 


RESETSTRINGPOOLSIZE 


CD 


INTRINSIC_ARRAYSEARCHP 


ARRAYSEARCHP 


D5 


INTRINSIC_GETLIBATTRIBUTES 


GETLIBATTRIBUTES 


D9 


INTRINSIC_SETLIBATTRIBUTES 


SETLIBATTRIBUTES 


DA 


INTRINSIC_HIGHESTPNUM 


HIGHESTPNUM 


DE 


INTRINSIC_HAPPENEDP 


HAPPENEDP 


E4 


INTRINSIC_AVAILABLEP 


AVAILABLEP 


E5 


INTRINSIC_MULTIWAIT 


MULTIWAIT 


E9 


INTRINSIC_SIMPLEWAIT 


SIMPLEWAIT 


EA 


INTRINSIC_DELINKLIBRARY 


DELINKLIBRARY 


EB 


INTRINSIC_DESC_HIDING 


DESC_HIDING 


EE 


INTRINSIC_ILOK_OK 


ILOK_OK 


FO 


INTRINSIC_ILOK_STATUS 


ILOK_STATUS 


Fl 


INTRINSIC_ILOK_BREAK 


ILOK_BREAK 


F2 
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Table 3-1. Intrinsic Identifiers 



Intrinsic Identifier 


MCP Identifier 


Number 


INTRINSIC_ILOK_ARROGATE 


ILOK_ARROGATE 


F3 


INTRINSIC_ILOK_LOCKING 


ILOK_LOCKING 


F4 


INTRINSICJLOKJJNLOCKING 


ILOK_UNLOCKING 


F5 


INTRINSIC.FAJACKET 


FAJACKET 


FA 



Note: Address equating another declaration to a declared intrinsic identifier has one 
unusual effect. If the stack cell was associated with the intrinsic (the intrinsic 
was the first declaration assigned to the cell), the normal initialization is 
overridden and the new declaration is used to initialize the cell. 



Examples 

PROCEDURE CAUSEP=(0,150) (E.HOW); 

INTRINSIC INTRINSIC_CAUSEP = CAUSEP; 
INTRINSIC INTRINSIC_EBCTOHEX; 

TRANSLATETABLE EBCTOHEX = INTRINSIC_EBCTOHEX (...); 
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LABEL Declaration 

<label declaration> 



— LABEL -. ,— <1 abel identifier- 1 

L [BAD] J 

Explanation 

In NEWP, a bad GO TO is a GO TO statement that branches out of the segment or 
procedure in which the GO TO statement appears. A label that is the object of a bad GO 
TO statement must be declared in a label declaration that includes the [BAD] syntax. 

Example 

LABEL [BAD] ENDITALL, ERROREXIT; 
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LIBRARY Declaration 

<library declaration> 



— LIBRARY > 



*— I— <1 i brary i denti f i er>— . 

I— ( <li brary attribute specifications> ) 



<library attribute specifications> 



9 

T—<Boolean library attribute specification> r 

— <string library attribute specification> 

— <mnemonic library attribute specification — 
— <procedure library attribute specification— 



<Boolean library attribute specification 

— <Boolean-valued library attribute name>— j— 



-r- TRUE — 
L- FALSE - 1 



<Boolean-valued library attribute name> 

— SYSTEMLIB 



(All other syntax is identical to ALGOL.) 
Explanation 

In NEWP, a value for the Boolean-valued library attribute SYSTEMLIB can be specified. 
When SYSTEMLIB is TRUE, the associated library is to be initiated as a system library, 
which allows it to access protected library entry points. For more information, see 
"EXPORT Declaration" in this section. Use of this attribute requires that the MCP compiler 
control option be set. 

In NEWP, a maximum of 4095 libraries can be declared in a single program. 

For more information related to the LIBRARY declaration, see "EXPORT Declaration" in 
this section and Section 7, "Compiler Controls." 
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MODULE Declaration 



Note: Wherever possible, use this version of the MODULE declaration. If you are 
unable to use this version for work on previous releases, use the version 
described in "MODULE Declaration (Old)" later in this section. 

<module declaration> 

— MODULE — <module identifiers 



L-<module head>— I 



BEGIN — <module identifier 
->-<module body> 



END — <module identifiers 

<module identiller> 

— <i denti f i er> 



<module head> 



<declaration> 



<module body> 



<declaration> — ; 



^alternative: 



^initial ization procedure: 



<interface declaration> 

— INTERFACE i nterf ace>- 



<interface> 

— <i nterf ace identifier — <i nterf ace body>- 
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<interface body> 



— ( 1 I <exportable identifier . 1 ) 1 

^interface identifier — ' 

<moduleexport declaration> 

— MODULEEXPORT -L<interface identifiers^ 1 

<moduleimport declarations 

r* > 1 

— MODULEIMPORT - L <i nterf ace identifier- 1 1 

<remote module declaration> 

— INCLUDE — <module identifier 1 

<interface identifier> 

— <i denti f i er 1 

<exportable identifler> 

— <i denti f i er 1 

Explanation 

A module, in NEWP, is a self-contained package that includes a number of declarations. 
By default, none of its declarations is visible outside the bounds of the module, and no 
identifiers declared in any other modules (nested, sibling, or enclosing) are visible within 
the module. The module import and export declarations provide the means to allow 
visibility of declarations across module boundaries. 

On the export side, INTERFACE declarations collect items declared within the module 
and group them under the interface identifier. The interface can then be exported with the 
MODULEEXPORT declaration, which makes it available for import into modules outside 
the scope of the exporting module. No MODULEEXPORT declaration is necessary to 
import an interface into a nested module. 
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The following restrictions govern the items that can appear in an interface: 

• Items imported from outside the module cannot be reexported. 

• The enumerated literals of an enumerated data type cannot themselves be included in 
an interface but are automatically included when the type, descendant of the 
enumerated type, or structure type variable descended from the enumerated type is 
included. 

• Items of a structure block can be included in an interface declaration provided the 
items have already been fully defined within the structure block type declaration. 

An item can appear in more than one interface. An item imported by a nested module can 
be included in an interface formed by the parent or grandparent, for example. An item 
must be declared before it can be included in an interface. 

If an interface identifier appears in the list of items (for another interface), all the items 
contained in the referenced interface are also contained in the interface being declared. 
This provides a convenient mechanism for building a large interface out of smaller ones. 
Components of a composite interface can also be overlapped. Only interfaces already 
defined within the same module, or imported from a nested module, can be used to build 
this kind of composite interface. 

If an interface identifier from a nested submodule appears in the MODULEEXPORT 
declaration, the entire interface is reexported, under its own name, from the parent 
module. This provides a mechanism for grouping modules, while still retaining their 
individual identities. 

The MODULEIMPORT declaration makes the items collected in the named interface 
visible within the importing module. An interface appears as a window across the 
boundary between two modules. If a module imports several interfaces exported from 
another module and items appear in more than one of these interfaces, there is no conflict 
or ambiguity. The windows simply overlap. 

A MODULEIMPORT declaration is required for all uses of an identifier within a module 
different from that in which it was declared. This means that interfaces must be declared 
and imported from parent to child, child to parent, and sibling to sibling. Alternatives 
within modules are not considered to be nested modules for this purpose, and therefore 
the alternatives directly inherit the environment of the containing module. 

Interfaces exported from a nested module can be imported by the parent or a sibling. 
Items exported from a nested module, in the head of the parent, can be included in 
interfaces exported from the parent. In addition, entire submodule interfaces are available 
for reexport under the original interface name. 

The REMOTE MODULE declaration is a feature intended for use on large modularized 
programs, such as the MCP. This declaration reorganizes the relationships among the 
modules without physically reorganizing the source files. It is not intended as a tool for 
construction of new programs. 
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The effect of the REMOTE MODULE declaration is as if the actual text of the designated 
module appeared at the point of the INCLUDE portion of the declaration. All scope rules 
are applied as if this were the case. The module included is then no longer eligible for 
compilation again either through another INCLUDE portion or in the normal location 
defined by the physical order of appearance. The included module is effectively removed 
from the source. The REMOTE MODULE declaration is not related to the compiler control 
option $INCLUDE. 

The target module must appear in the source as a member of the same contiguous group 
of modules as the module that invokes the REMOTE MODULE declaration. The REMOTE 
MODULE declaration can appear only as a declaration in the heading or the body of the 
host module, not within a nested module or procedure. However, a nested module can 
include another nested module from its own contiguous group. 

Scope Rules 

The declaration of an interface makes the interface identifier known throughout the rest 
of the module declaring it. This includes any later nested modules. The export of an 
interface identifier makes that identifier known throughout the rest of the environment 
containing the exporting module. The exporting module includes later sibling modules. If 
the exporting module is an outermost module, the interface name is known throughout the 
rest of the program. If a module is declared within a procedure or block, the scope rules 
restrict the visibility of any exported interfaces to the rest of the body of the procedure or 
block. 

The ALGOL rules apply to the declaration of interfaces with the same name. A potential 
conflict can arise if two or more interfaces with the same name appear in the same scope. 
This can occur by local declaration, by export from a nested or sibling submodule, or by 
import from the outer environment. If one of the conflicting declarations appears within a 
scope properly nested within the scope containing the other interface, the outer name 
becomes invisible in the inner scope. If the conflicting declarations arise in the same 
scope, the situation is flagged as a compilation error. For more information on scope, refer 
to the ALGOL Programming Reference Manual, Volume 1: Basic Implementation. 

The declaration and export of an interface does not, however, make the items collected in 
the interface automatically visible outside of the declaring module, or within any nested 
submodules. When an interface identifier appears in a MODULEIMPORT declaration, the 
identifiers contained within the interface become visible through the rest of the scope 
within which the import declaration appears. These identifiers appear to belong to that 
scope. The ALGOL scope rules apply to the point of import. 

MODULE, INTERFACE, MODULEEXPORT, and MODULEIMPORT declarations are true 
declarations. As such, they can appear anywhere that declarations are allowed. However, 
if an interface is to be exported, its declaration must appear in the heading of the module, 
not nested within any procedure or block. 
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The order of compilation and the scope definition of after in NEWP is first line to last line, 
with the following exception related to modules: contiguous sibling modules are compiled 
as a group. Within the group, the order of compilation is heads (first to last), then bodies. 
Nested submodules, including groups of adjacent sibling submodules, are compiled where 
they appear within this order. If a group of modules is nested in the head of the parent 
module, the compilation of the bodies of the nested modules is deferred to the beginning 
of the body of the parent. 

Imports must be specified before they are used, when establishing a compilation order. 
Appearance of an identifier within a DEFINE body does not constitute a use. However, an 
invocation of such a DEFINE would be a use. A given interface can be imported safely 
more than once into the same environment. 

MODULE Declaration (Old) 

Note: Do not use this version of the MODULE declaration unless your work on 

previous releases requires it. Wherever possible, use the version described in 
"MODULE Declaration" in this section. 

<module declaration> 

— MODULE — <module identifier — ; — ■ . > 

I— <module head>— ' 

■*- BEGIN — <module identifier* — ; > 

->-<module body> > 

END — <module identifier — ; 1 



<module identifier* 

— <i denti f i er> 



<module head* 



L<export list> — ; —I L_< SU ppiy decl aration>— ' 



-»— declarations 



<export list* 

— EXPORT identifier- 
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<module body> 



<declaration> — ; 



-<al ternati ve>- 



-<initial ization procedure> 



T 



<alternative> 

— ALTERNATIVE — <al ternati ve identifier>- 



r ; 

SELECT — <constant Boolean expression^ 
BEGIN — alternative identifier — ; 



<declaration> 



END — <al ternati ve identifier 

alternative identifier> 

— <i denti f i er> 



<initialization proceduro 

INITIALIZATION PROCEDURE — procedure heading>- 



L<procedure type>— ' 
procedure body> 



Explanation 

The MODULE declaration allows logically related declarations to be grouped together. 
Items declared within a module are protected, in the sense that they are not visible to 
other modules unless specified in an EXPORT list. 

Exported identifiers must be declared in the <module head>. The form of the declarations 
for procedures to be exported depends on whether or not the procedure is declared to be 
INLINE (see "In-Line Procedures" in this section). Non-in-line procedures to be exported 
are declared in the module head as they would be declared anywhere else, except that the 
<procedure body> must be LIBRARY, EXTERNAL, NULL, or FORWARD; if the procedure 
body is FORWARD, the procedure must be fully declared in the <module body>. In-line 
procedures to be exported cannot be declared EXTERNAL, NULL, or FORWARD and must 
be fully declared in the module head. 
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Note: The keyword EXPORT is interpreted as a module <export list> when it appears 
in the module head of a MODULE declaration. EXPORT in any other context is 
interpreted as a library EXPORT declaration. When a library entry point is 
declared in the module head by using the <library entry point specification, 
any other entry points to the library to be used in the module must also be 
declared in the module head. If no entry points are to be used in the module 
head, then this restriction is inapplicable. 

MODULE <module identifier>, BEGIN <module identifier>, and END <module 
identifier> must be the first tokens on the records on which these module identifiers 
appear. In a single <module declarations-, the three occurrences of the module identifier 
must all be the same identifier. The BEGIN <module identifier> and the END <module 
identifiers cannot be part of an INCLUDE file, nor part of a define. 

Modules can be nested up to 50 deep. Selectable modules can be used at any point in the 
nesting. For more information, see the "SELECT Statement" in Section 4, "Statements." 

Within a given outer level module, the code for all initialization procedures is placed in 
one single segment. For example, the initialization procedure of a selectable submodule is 
in the same segment as the initialization procedure of its selectable parent when modules 
are configured as such. 

Items declared to have scalar types can be exported by and imported into modules. 
Alternatives 

The specification of alternatives allows the compile-time or run-time selection of one 
group of declarations from a list of one or more alternative groups. The selection is made 
at compile-time by providing a SELECT clause on the alternative declaration whose 
Boolean expression evaluates to TRUE. Only one alternative can be selected at compile 
time. Run-time selection is made by an initialization procedure>, which must be declared 
if alternatives are declared (and can be declared even if no alternatives are declared). 

EXPORT declarations are not allowed within alternatives. 

If an initialization procedure occurs in a module, all items declared in the module, except 
the initialization procedure, are unavailable until the initialization procedure is entered. At 
that time, the items declared in the module but outside any alternatives are initialized. 
Items declared in an alternative are not available until, and unless, a SELECT statement 
for that alternative is executed. For more information, see "SELECT Statement" in Section 
4, "Statements." 

Items declared in a module but outside all alternatives are available inside all alternatives 
in that module. 

If a procedure is declared inside the alternatives but is visible outside the alternatives, 
either because it is exported or because it is declared FORWARD, its actual declaration 
must appear in every alternative in the module and must have the same procedure heading 
in every declaration. That is, the procedure type, number of parameters, type of 
parameters, and all other information contained in the procedure heading (except formal 
parameter identifiers) must be identical. 
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In a single <alternative> specification, the three occurrences of alternative identifier 
must all be the same identifier. Alternatives cannot contain procedures declared to be 
EXTERNAL. 

The NEWP compiler attempts to reuse D[0] cells for different alternatives within the same 
module. Cells that cannot be reused are those holding segment descriptors, value arrays, 
library templates and markers, and double-precision items. The attempt to reuse D[0] cells 
occurs only when the MCP control option is set. 

Initialization Procedures 

An initialization procedure is declared much like a standard procedure, except that the 
keyword INITIALIZATION must follow the procedure type (if any) and must precede the 
keyword PROCEDURE. Initialization procedures are the only procedures that can contain 
SELECT statements. 

Initialization procedures are subject to the following restrictions: 

• An initialization procedure can occur only as the last declaration in a module body. 

• An initialization procedure can be executed only once. An INVALID OPERATOR fault 
occurs if an attempt is made to execute an initialization procedure a second time. 

• The SEGMENT block directive cannot be specified in the block directives for an 
initialization procedure. 

• The INLINE block directive cannot be specified in the block directives for an 
initialization procedure. 

For more information related to the MODULE declaration, see "EXPORT Declaration," "In- 
Line Procedures," and "SUPPLY Declaration" in this section and "SELECT Statement" in 
Section 4, "Statements." 

Example 

BEGIN 

MODULE PHYSICALIO; 

EXPORT PHYSICALIOJNITIALIZATION, 
DOCHARIO, 
T; 

BOOLEAN INITIALIZATION PROCEDURE 

PHYSICALIOJNITIALIZATION (WHICHONE) ; 

VALUE WHICHONE; BOOLEAN WHICHONE; FORWARD; 
PROCEDURE DOCHARIO; FORWARD; 
INTEGER T; 
BEGIN PHYSICALIO; 
REAL R; 

ALTERNATIVE MLI P_PHYSICALIO; 
BEGIN MLIP_PHYSICALIO; 

INTEGER I; 

PROCEDURE DOCHARIO; 
BEGIN 

END DOCHARIO; 
END MLIP_PHYSICALIO; 
ALTERNATIVE MPX PHYSICALIO; 
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BEGIN MPX_PHYSICALIO; 

PROCEDURE DOCHARIO; 
BEGIN 

END DOCHARIO; 
REAL PROCEDURE I0FINISH68; 
BEGIN 

END I0FINISH68; 
END MPX_PHYSICALIO; 
BOOLEAN INITIALIZATION PROCEDURE 

PHYSICALIOJNITIALIZATION(WHICHONE) ; 

VALUE WHICHONE; BOOLEAN WHICHONE; 

BEGIN 

IF WHICHONE THEN 

SELECT(MLIP_PHYSICALIO) 

ELSE 

SELECT(MPX_PHYSICALIO); 
PHYSICALIO_INITIALIZATION:=WHICHONE; 

END PHYSICALIO_INITIALIZATION; 
END PHYSICALIO; 
MODULE INITIALIZER; 

EXPORT GETITGOING; 

PROCEDURE GETITGOING; 

FORWARD; 
BEGIN INITIALIZER; 

IMPORT FROM PHYSICALIO(PHYSICALIOJNITIALIZATION) ; 

BOOLEAN WHICHONE; 

PROCEDURE GETITGOING; 

BEGIN 

PHYSICALIOJNITIALIZATION (WHICHONE) ; 
END GETITGOING; 
END INITIALIZER; 
GETITGOING; 

END. 
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ON Declaration 

<on declaration> 

— ON — <fault list>— 1 1— , — <statement> 1 

I— <fault information part>— ' 

Explanation 

The ON declaration provides a fault-handling mechanism similar to the mechanism 
available through the ALGOL ON statement. When a fault named in the fault list occurs, 
control is transferred to the fault-handling statement appearing in the ON declaration. To 
resume normal execution, a GO TO statement to a label outside of the <statement> in the 
ON declaration must be performed (except in the case of an EXPONENT UNDERFLOW 
fault). The execution of a bad GO TO statement can cause the invocation of an 
EXCEPTION procedure. For more information, refer to "EXCEPTION PROCEDURE 
Declaration" in this section. 

If a GO TO statement is not performed, the MCP searches down the program's execution 
stack for another enabled fault-handling declaration. This process continues until either a 
GO TO statement is performed or the entire execution stack has been searched. In the 
latter case, if the fault was EXPONENT UNDERFLOW, the program continues processing 
with a zero substituted for the result of the operator that caused the underflow. 
Otherwise, the program is terminated by a DS system command, which causes any 
EXCEPTION PROCEDURES to be executed. Refer to "EXCEPTION PROCEDURE 
Declaration" in this section for more information. 

The fault numbers must be only single-precision, arithmetic <simple variable>s, while the 
fault names include all those available in ALGOL. For more information on <fault number> 
and <fault name>, see the ALGOL Programming Reference Manual, Volume 1: Basic 
Implementation. 

In addition, the following faults are available in NEWP: 

• LOCKEDFAULT(20) 

• LIBLINKFAULT(21): Occurs if an attempted library linkage is unsuccessful 

• MEM0RYFAIL1(23): B 7900 fault 

• PRIVILEGEDINSTRUCTION(24): B 7900 fault 

• PARITYFAIL1(25): B 7900 fault 
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If the B 7900 compiler control option is TRUE, the following faults are not included in 
ANYFAULT fault list, although they can be specified as individual fault names: 

• LOOP 

• MEMORYPARITY 

• INVALID ADDRESS 

• SCANPARITY 

• INVALIDPROGRAMWORD 

• MEMORYFAIL1 

• PARITYFAIL1 

For information about the ANYFAULT fault name, see the ALGOL Programming 
Reference Manual, Volume 1: Basic Implementation. For information about the B 7900 
compiler control option, see Section 7, "Compiler Controls." 

Example 

ON ANYFAULT, 
BEGIN 

RUNSTATUS:= FIRSTPR0C_FAULT; 

GO TO ERRLABEL; 

END; 

OUTPUTMESSAGE ARRAY Declaration 

Outputmessage arrays are declared as in ALGOL except for the following differences: 

• Implicit string concatenation in NEWP requires at least one blank, or the use of a 
<string concatenation operators 

• NULL or EMPTY strings are not allowed, but a string of one or more blanks is allowed. 
For example: 

■I n 

• A <numeric constant> is accepted at all places where a number is accepted. 
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PENDING PROCEDURE ACTUAL Declaration 

<pending procedure actual declaration 

PROCEDURE 



I— <procedure type>— ' 



r<- 



>— ^structure block type identifier— 1 — . — <procedure heading> — ; 
compound statement> 



The PENDING PROCEDURE ACTUAL declaration in NEWP is similar to the PENDING 
PROCEDURE ACTUAL declaration in ALGOL, with the following differences. 

NEWP allows the pending procedure of an embedded structure or connection block to be 
declared outside the structure or connection block that contains the embedded structure 
block. This syntax is necessary when structure or connection block types and their 
pending procedures are declared in the header of a module. 



Example 

REAL X; 

TYPE SB = STRUCTURE BLOCK 
BEGIN 

PROCEDURE P; PENDING; 

TYPE SBINNER = STRUCTURE BLOCK 

BEGIN 

REAL X; 

PROCEDURE PINNER; PENDING; 

END 
REAL X; 
REAL R; 
REAL Z; 
END; 



REAL R; 
REAL Z; 

PROCEDURE SB.P; 
BEGIN 
REAL Z; 

X:= 100; % Updates X contained in SB 

R:= 100; % Updates R contained in SB 

Z:= 100; % Updates Z contained in procedure PINNER 

END; 

PROCEDURE SB. SBINNER. PINNER; 
BEGIN 
REAL Z; 

X:= 100; % Updates X contained in SBINNER 

R:=100; % Updates R contained in SB 

Z:= 100; % Updates Z contained in procedure P 

END; 
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POINTER Declaration 



ASCII - 
EBCDIC -\ 
HEX — 



POINTER 



<pointer identifier>- 



-<lexical level restriction part> 
L [ — UPLEVEL — ] 



Explanation 

Pointers can be declared with a size specification (for example, HEX). If the character size 
is not specified, the default is EBCDIC. 

The <lexical level restriction part> construct has the same syntax and semantics in NEWP 
as it does in ALGOL. UPLEVEL pointers are allowed only if the MCP compiler control 
option is set or the block is in UNSAFE (UPLEVEL) mode. 

Usage of UPLEVEL pointers can result in an excessive number of warnings from the 
compiler. However, pointers that have been declared UPLEVEL do not receive compiler 
warnings when usage of the pointers results in an UPLEVEL reference. Declaring 
UPLEVEL pointers does not affect the UNSAFE block directive UPLEVEL. The UNSAFE 
block directive UPLEVEL is still required for blocks containing UPLEVEL references. The 
<lexical level restriction part> and UPLEVEL options are mutually exclusive. Only one 
may be selected in each POINTER declaration. 

Syntax errors are given for pointer and string size mismatches. For example, if PTR is 
declared as an EBCDIC pointer, the following statement causes a syntax error: 



REPLACE PTR BY 4"FF00"; % SHOULD BE 48"FF00" 



Example 

EBCDIC POINTER PTRIN, PTROUT; 
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PROCEDURE Declaration 



<procedure declaration> 



I— <procedure type>— ' 
procedure body> 



PROCEDURE — <procedure heading>— ; 



<procedure type> 



<type>- 



<procedure heading> 

— <procedure i denti fier>- 



-<formal parameter part> 
- ( ) 



<formal parameter part> 

— ( — <formal parameter list> — ) — ; 



<name part 



=specification>- 



<value part 



<name part> 



— NAME -L<i denti fier>-L ; 



<formal parameter list> 



cformal parameter>- 



<specification> 



-<speci f i er> — 1 — <i denti f i er>- 
=procedure specification>- 



<procedure reference array specification^ 
<array specification>- 



=structure block array specification>- 
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<specifier> 



ACTIVATION 

- CONNECTION 

- EVENT 



- DIRECT -I 

- INTERLOCK 



FILE 



ASCII - 

- EBCDIC 

- HEX — 



POINTER 



=set identifier>- 

|- TASK 

=type> 



=structure block type identifier>- 



=connection block type identifier 



<procedure specification> 

PROCEDURE 



L<proced 



ure type: 



7J 



=identifier>- 



( ) 

L <formal parameter part>— 1 



FORMAL 



<procedure reference array specification 

PROCEDURE REFERENCE ARRAY — <identifier>— [ 



procedure type: 

-*-<lower bound list>— ] -r- ( ) r- ; — FORMAL 

L-<formal parameter part>— ' 



<array specification 

L DIRECT -I L <array type>— ' 
lower bound list> — ] 



ARRAY — L- <array identifier— 1 — [ 



<structure block array specification 



structure block type identifier— 1 — ARRAY — 1 — <i denti f i er> — 1 — [ > 



lower bound list> — ] 
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<array type> 

— i— <array class>— r 

- EVENT 

- INTERLOCK 

L- TASK 1 



<lower bound list> 



— 1 — r— <i nteger> . — 1 

_ * 

— <constant scalar type expression- 
procedure body> 

— i— <compound statement> . 1 

- EXTERNAL 

— <library entry point specification^ 
— <dynamic procedure specification> 

(All other syntax is identical to ALGOL.) 
Explanation 

Procedures in NEWP are similar to procedures in ALGOL, with the following exceptions: 

• Parameters are passed as call-by-reference, call-by-value, or call-by-name. Parameters 
passed as call-by-name are permitted only for in-line procedures. 

• Procedures are declared INLINE through the INLINE block directive. 

• The procedure value of a typed procedure is accessed explicitly within the scope of 
the procedure through the <procedure identifier>. VALUE construct. 

• Use of <name part> is supported for in-line procedures. 

• The names of formal parameters to a procedure cannot be used again as local 
identifier declarations in the outer block of the procedure. 

You cannot use call-by-name parameters in the FOR specification of POINTER 
declarations. 

REAL, INTEGER, BOOLEAN, DOUBLE, POINTER, DESCRIPTOR, and WORD can be call- 
by-name parameters. DESCRIPTOR and WORD parameters can be used only in the 
appropriate UNSAFE mode. 
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Parameter Passing 

Parameters are passed as call-by-value, call-by-reference, or call-by-name. The default is 
call-by-reference. No more than 63 parameters are allowed on one procedure. Thunks are 
not implemented in NEWP. To pass a parameter as call-by-value, the <value part> must 
appear in the procedure heading. To pass a parameter as call-by-name, the <name part> 
must appear in the procedure heading of an in-line procedure. 

Actual parameters passed to call-by-reference formal parameters must generate address 
references. Constants and arithmetic expressions do not generate address references. 
However, conditional and case expressions are allowed if each branch generates an 
address reference. For parameters passed as call-by-reference, the types of the actual 
parameters and formal parameters must agree. For example, a variable of type REAL 
cannot be passed as call-by-reference to a formal parameter of type DOUBLE or 
INTEGER. 

If a call-by-reference formal parameter has a scalar type, the actual parameter passed to 
that formal parameter must be of the same type as the formal parameter. If a call-by-value 
formal parameter has a scalar type, the type of the actual parameter passed to that formal 
parameter must be assignment-compatible with the type of the formal parameter. 

If a call-by-reference formal parameter is a set type, the actual parameter and the formal 
parameter must have been declared with the same <set identifiers Sets cannot be passed 
as call-by-value. 

Call-by-name parameters do not cause anything to be stacked upon entry to the in-line 
procedure. Instead, the actual parameter is evaluated each time the formal parameter is 
used. 

If you store into a given call-by-name formal parameter or you use the parameter as the 
subject of nonevaluative type transfer (for example, WORD AT X), then its corresponding 
actual parameter must be of a form suitable for the actual parameter to a call-by-reference 
formal parameter. The actual parameter must be capable of generating an address 
reference. For an actual parameter, as for a call-by-reference parameter, implicit type 
coercion caused by type mismatch is allowed and is handled with nonevaluative type 
transfer, producing the same semantics. For example, if WORD W is passed to BOOLEAN 
parameter B, it is treated as if BOOLEAN AT W were passed. For information on implicit 
type coercion, see the ALGOL Programming Reference Manual,Volume 1: Basic 
Implementation. 

If you do not store into a given call-by-name formal parameter or you do not use the 
parameter as the subject of a nonevaluative type transfer, then its corresponding actual 
parameter must be in a form suitable for the actual parameter to a call-by-value formal 
parameter. The actual parameter need not be capable of generating an address reference. 
Implicit type coercion because of type mismatch is allowed to the same extent as for call- 
by-value parameters and is handled with evaluative type transfer, producing the same 
semantics. For example, if WORD W is passed to BOOLEAN parameter B, it is treated as if 
BOOLEANfW) were passed. 
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If CONNECTION or <connection block type identifier> was used as the specifier for the 
formal parameter, an individual connection library must be passed as the actual 
parameter. The actual parameter must be an indexed library connection variable unless 
the connection library has been declared with the SINGLE modifier. If the connection 
library has been declared with the SINGLE modifier, the actual parameter must be an 
unindexed connection library variable. In addition, the connection parameter must be a 
call-by-reference parameter. 

When CONNECTION is used as a specifier, the procedure cannot see the elements of the 
connection library associated with the connection parameter. The procedure can pass the 
connection parameter to MCP procedures and can access the connection attributes. The 
procedure cannot use the parameter either to call procedures within the connection 
library or to access non-connection attributes. 

Non-library procedures — procedures that are neither imported nor exported from a 
library — can specify either CONNECTION or a <connection block type identifier> for 
connection parameters. Using CONNECTION restricts the use of the parameter. Library 
procedures can only specify CONNECTION for a connection parameter. 

For more information on connection libraries, see the ALGOL Programming Reference 
Manual, Volume 1: Basic Implementation. 

The syntax for specifying procedures as formal parameters differs between NEWP and 
ALGOL. NEWP does not support run-time parameter checking; therefore, you must specify 
all parameters of formal procedures. 

Each dimension of a formal array parameter can be a scalar type. The scalar type must be 
a bounded, discrete type. If the lower bound of a dimension is specified by a <constant 
scalar type expression;^ the type of the dimension is the type of the expression. When the 
procedure is invoked, the dimension of the actual array passed to the formal array must 
have the same scalar type as the corresponding dimension of the formal array. A lower 
bound specified by an asterisk (*) is of type INTEGER. 

In NEWP (unlike in ALGOL), DEFINES are not expanded when the compiler is processing 
the individual identifiers in the <value part> or specification part> of a procedure 
heading. 

Activation Variables 

Activation variables can be passed by value or by reference. If an activation variable is 
passed by reference to a formal activation parameter, a reference to the one-word 
activation skeleton SIRW is passed. The activation skeleton SIRW is the object and can be 
modified directly. 

An activation can also be passed by value. In this case, the actual activation skeleton 
SIRW is passed, and the original skeleton SIRW cannot be modified through the formal 
parameter. 

An untyped activation expression can be passed to a typed activation variable only under 
the UNSAFE(MISC) directive. 
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In-Line Procedures 

In-line procedures combine some of the efficiency of DEFINES with the semantics of 
procedures. Each invocation of an in-line procedure results in an in-line expansion of its 
code at the point of the invocation. 

In-line procedures with local ARRAY or EVENT declarations are executed as procedures, 
that is, as block entry by means of a Program Control Word (PCW). Unlike normal 
procedures, the code for an enterable in-line procedure is always placed in the same 
segment as the code that invokes the in-line procedure. There is a performance penalty 
associated with enterable in-line procedures, so the declaration of local arrays and events 
in in-line procedures is discouraged. 

An in-line procedure is declared by including the keyword INLINE as a block directive 
associated with the first BEGIN of the procedure body (see "Block Directives" in 
Section 7, "Compiler Controls"). In-line procedures are subject to the following 
restrictions: 

• An in-line procedure that is exported from a module must be fully declared in the 
module head. For more information, refer to "MODULE Declaration" in this section. 

• The only imported items an exported in-line procedure can use are those exported 
from modules declared prior to the module containing the exported in-line procedure. 

• In-line procedures must not be recursive. 

• An in-line procedure cannot be passed as a formal parameter to a procedure that is 
not an in-line procedure. However, both in-line and other procedures can be passed as 
formal parameters to in-line procedures. 

• The <procedure identifier referred to in a RUN, PROCESS, or FORK statement must 
not be that of an in-line procedure. 

• The procedure identifier referred to in the CONTROL form of the <freeze statement> 
must not be that of an in-line procedure. 

• An in-line procedure cannot be exported as a library entry point. 

• Noninvocation references to in-line procedures (such as in a MAKEPCW or 
LEXOFFSET call) are, in general, not allowed. However, <procedure 
identifiers. VALUE is a noninvocation reference that can reference an in-line 
procedure from within the body of the procedure. 

• The RETURN and EXIT functions for NEWP are not allowed within the body of an in- 
line procedure. For more information, refer to "Intrinsics (UNSAFE)" in Section 8, 
"UNSAFE Mode." 

• An in-line procedure cannot be declared FORWARD, EXTERNAL, or NULL. 

• An initialization procedure cannot be an in-line procedure. For more information, see 
"MODULE Declaration" in this section. 

• An in-line procedure cannot be used in a SORT statement. 

In-line procedures are similar in many respects to both DEFINES and regular procedures. 
However, there are differences that should be taken into account when you are deciding 
which should be used. 
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The primary difference between an in-line procedure and a DEFINE is that in-line 
procedures apply regular scope rules, evaluate parameters like regular procedures do 
(except for NAME parameters), and are treated as procedures for LINEINFO and XREF. 
For information on LINEINFO and XREF, see the ALGOL Programming Reference 
Manual, Volume 1: Basic Implementation. 

In-line procedures differ from regular procedures in several ways. Functionally, in-line 
procedures provide NAME parameters and the INHERITSTATE block directive. Regular 
procedures always require a PCW, while in-line procedures generally do not; therefore, no 
stack cell is allocated for one. The code of an in-line procedure is always present in the 
segment that contains the call, so you do not need to think about where to take presence 
bits (pbits). The TADS option can be used with regular procedures, but not with in-line 
ones (a syntax error is received), though in many cases simply omitting the [INLINE] 
block directive when TADS is set can help you to avoid receiving an error. 

Because all the code for an in-line procedure exists in each place it is invoked (rather than 
just having the procedure entry code), using a large in-line procedure in many places 
affects the code file size. 

The cost of doing an ENTR/EXIT operation is avoided with an in-line procedure (except 
when ARRAY or EVENT declarations are used), but having a large number of parameters 
or locals offsets this advantage. This is because each parameter and local must be deleted 
off the stack at the end of the in-line. The point at which the cost of deleting the 
parameters and locals exceeds the savings from not doing the ENTR/EXIT operations 
differs on each machine. 

Finally, in-line procedures cannot be passed as parameters, and if exported from a 
module, these procedures must be fully declared in the module head. 

In general, you must consider a number of these factors when you are deciding whether to 
use a define, in-line, or regular procedure. The functionality (that is, the use of NAME 
parameters, the use of INHERITSTATE block directives, the acceptability of p-bits, the use 
of TADS, and so on) should be considered first. This should be weighed against the PCW 
requirement of a regular procedure (some primitive software can have problems 
addressing PCWs). The final factor should be the size and performance of the code file. If 
you take all these factors into account, you can make an appropriate choice. 

The LINEINFO references for an expanded in-line procedure include both the sequence 
number or numbers of the invoking code and the sequence number of the invoked code. 
These sequence numbers are listed in order from most recently invoked procedure or 
block to least recently invoked procedure or block. For more information on LINEINFO, 
see the ALGOL Programming Reference Manual, Volume 1: Basic Implementation. 
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More efficient code is emitted for certain typed in-line procedures. The value returned is 
generated on top of the stack and no cell to hold the value is pushed to the stack when the 
following conditions apply: 

• No parameters to the in-line procedure need be stacked. Call-by-name parameters 
never stack their actual parameters. Call-by-reference parameters do not stack their 
actual parameters when simple variables are passed to them. Call-by-value parameters 
do not stack their actual parameters when constants are passed to them. 

• The in-line procedure has no local variables requiring stack cells. (DEFINES and 
CONSTANTS are acceptable.) 

• The only reference to the procedure value is the final statement, which stores to it. 
This statement must be executed unconditionally and must not be spanned by a 
looping structure or followed by a label. 

Note: If the in-line procedure ends with a combination of IF THEN. . . ELSE statement 
constructs that depend on a constant expression or expressions, then only the 
statement or compound statement that is executed need meet these constraints. 

When a program passes a call-by-reference parameter through the MAPPING function, an 
unexpected syntax error can occur. The cause of this error is a formal parameter that has 
been used as the destination of an ASSIGNMENT statement in the procedure. The syntax 
error itself occurs when the in-line procedure is invoked, reporting that an assignment or 
declaration incompatibility has occurred. If the reason for the incompatibility is not 
apparent, then it might be due to a peculiarity in the way in-lines are invoked. Examine the 
declaration of the formal parameter and consider whether it might be better declared as 
call-by-value or call-by-name. If a change in declaration is appropriate, then you must 
apply the same MAPPING function to the formal parameter at each place in which it is the 
object of an assignment. 
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Procedure Value 

Within the body of a typed procedure, the value of the procedure can be accessed through 
the following syntax: 

<procedure identifier^. VALUE 

This construct is treated as a primary of the same type as the declared procedure and, as 
such, can be used in expressions, assignments, and address equations. 

The value returned by a scalar type procedure is undefined if no value is assigned to the 
procedure during the execution of the procedure. 

Example 

REAL PROCEDURE PROC; 
BEGIN 

BOOLEAN B; 

PROC.VALUE:= 10; 

IF PR0C.VALUE=20 THEN 



END PROC; 

Dynamic Procedure Specification 

Dynamic procedure specification is the same in NEWP as it is in ALGOL, except that the 
<selection procedure identifier must specify an untyped procedure with three 
parameters. The first parameter must be a real array, specified with a constant (not star- 
bounded) lower bound. The second parameter must be a call-by-value integer. The third 
parameter must be a fully specified untyped procedure with one parameter that is a task. 
When the MCP invokes the selection procedure, the task variable passed to its procedure 
parameter must already be associated with a library that has been processed using this 
task variable. 

The following example shows the use of a <dynamic procedure specification>. The 
example assumes that its object file is named OBJECT/SAMPLE/DYNAMICLIB and that a 
library called OBJECT/SAMPLE/LIBRARY that exports the procedure DATEANDTIME as 
DAYTIME also must be available. 
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Examples 

The following NEWP library, compiled as OBJECT/SAMPLE/LIBRARY, provides its entry 
points directly. 

BEGIN 

ARRAY MSG [0:120]; 

INTEGER PROCEDURE FACT(N); 
INTEGER N; 

BEGIN 

IF N LSS 1 THEN 

FACT:= 1 
ELSE 

FACT:= N * FACT(N - 1); 
END; % OF FACT 

PROCEDURE DATEANDTIME(TOARRAY, WHERE) ; 
ARRAY T0ARRAY[*] ; 
INTEGER WHERE; 

BEGIN 
REAL T; 
POINTER PTR; 

T:= TIME(7); 

PTR:= P0INTER(T0ARRAY,8) + WHERE; 
CASE T. [5:6] OF 
BEGIN 

0: REPLACE PTR: PTR BY "SUNDAY, "; 
1: REPLACE PTR: PTR BY "MONDAY, "; 
2: REPLACE PTR: PTR BY "TUESDAY, "; 
3: REPLACE PTR: PTR BY "WEDNESDAY, "; 
4: REPLACE PTR: PTR BY "THURSDAY, "; 
5: REPLACE PTR: PTR BY "FRIDAY, "; 
6: REPLACE PTR: PTR BY "SATURDAY, "; 
END; 

REPLACE PTR BY T. [35:6] FOR 2 DIGITS, 

T. [29:6] FOR 2 DIGITS, 

T. [47:12] FOR 4 DIGITS, ", ", 

T. [23:6] FOR 2 DIGITS, ":", 

T. [17:6] FOR 2 DIGITS, ":", 

T. [11:6] FOR 2 DIGITS; 
END; % OF DATEANDTIME 
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EXPORT FACT,DATEANDTIME AS "DAYTIME"; 
REPLACE POINTER(MSG) BY 

" - SAMPLE LIBRARY STARTED", 
" " FOR 94; 
DATEANDTIME(MSG,60) ; 
FREEZE(TEMPORARY) ; 
END. 

The following NEWP library, compiled as OBJECT/SAMPLE/DYNAMICLIB, illustrates 
dynamic and indirect library linkage. 

BEGIN [UNSAFE (FORK)] 
TASK LIB1TASK, LIB2TASK; 

PROCEDURE DYNLIB1; 

% LIBRARY PROVIDED DYNAMICALLY AND INDIRECTLY 
BEGIN % PRINTS DATE WITH TIME 
LIBRARY SAMLIB (TITLE = "OBJECT/SAMPLE/LIBRARY."); 
PROCEDURE DAYTIME (TOARRAY, WHERE); 

ARRAY TOARRAY [*] ; 

INTEGER WHERE; 

LIBRARY SAMLIB; 
EXPORT DAYTIME; 
FREEZE (TEMPORARY); 
END; % OF DYNLIB1 

PROCEDURE DYNLIB2; 
% LIBRARY PROVIDED DYNAMICALLY 

BEGIN % PRINTS OUT DATE WITHOUT TIME 
PROCEDURE DAYTIME (TOARRAY, WHERE); 
ARRAY TOARRAY [*] ; 
INTEGER WHERE; 

BEGIN 

REAL T; 

T:= TIME (7); 

REPLACE POINTER (TOARRAY, 8) + WHERE 
BY T. [35:06] FOR 2 DIGITS, 
T. [29:06] FOR 2 DIGITS, 
T. [47:12] FOR 4 DIGITS; 
END; % OF DAYTIME 
EXPORT DAYTIME; 

FREEZE (TEMPORARY); 
END; % OF DYNLIB2 
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% THE SELECTION PROCEDURE 

PROCEDURE THESELECTIONPROC (LIBPARAM, LIBPARAMLEN, NAMINGPROC) ; 
VALUE LIBPARAMLEN; 
ARRAY LIBPARAM [0] ; 
INTEGER LIBPARAMLEN; 
PROCEDURE NAMINGPROC (LIBTASK); 
TASK LIBTASK; FORMAL; 

BEGIN 

IF POINTER(LIBPARAM) EQL "WITH TIME" THEN 
BEGIN 

IF LIB1TASK. STATUS NEQ VALUE (FROZEN) THEN 

PROCESS DYNLIB1 [LIB1TASK] ; 
NAMINGPROC (LIB1TASK) ; 
END 

ELSE 

BEGIN 

IF LIB2TASK. STATUS NEQ VALUE (FROZEN) THEN 

PROCESS DYNLIB2 [LIB2TASK] ; 
NAMINGPROC (LIB2TASK) ; 
END; 

END; % OF THE SELECTION PROCEDURE 

PROCEDURE DAYTIME (TOARRAY, WHERE); 
ARRAY TOARRAY [*] ; 
INTEGER WHERE; 
BYCALLING THESELECTIONPROC; 

EXPORT DAYTIME; % PROVIDED DYNAMICALLY 

FREEZE (TEMPORARY); 

END. 

The following example invokes the library in the preceding example: 
BEGIN 

LIBRARY MYLIB (TITLE = "OBJECT/SAMPLE/DYNAMICLIB. ") ; 

PROCEDURE DAYTIME (A, W) ; 
ARRAY A [*] ; 
INTEGER W; 
LIBRARY MYLIB; 

REAL T; 

INTEGER X,Y; 

ARRAY DATIME [0:120] ; 

REPLACE MYLIB. LIBPARAMETER BY "WITH TIME."; 
X:= 13; 
Y:= 40; 

DAYTIME (DATIME [*] , Y) ; 
END. 
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PROLOG PROCEDURE Declaration 

In addition to the restriction outlined in the ALGOL manual, in NEWP the following 
restrictions also apply to PROLOG procedures: 

• The PROLOG procedure body cannot be declared as NULL. 

• A PROLOG procedure cannot be address equated. 

• The INLINE block directive cannot be used for PROLOG procedures. 

SEGMENT Declaration 

<segment declaration> 

r* > — : 1 

— SEGMENT — <segment identifier^— 1 



— <i denti f i er> 1 

Explanation 

The SEGMENT declaration defines one or more identifiers for use in referring to code 
segments. OUTERBLOCK is a predeclared segment identifier that refers to the code 
segment containing the code for the outer block of the program. 

Segment identifiers can be used in the SEGMENT block directive to specify the segment 
into which the compiler is to put the code for that block. For more information, refer to 
"Block Directives" in Section 7, "Compiler Controls." 

Example 

SEGMENT SCANSEG, 
PARSESEG, 
EMITTERSEG; 
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SIMPLE VARIABLE Declaration 

<simple variable declaration> 

<Boolean decl aration> . 1 

— <double decl aration> 

— <integer declaration> 

— <real declaration> 

— <scalar type variable declaration— 

<scalar type variable declaration> 

A <structure type variable declaration> used to declare subtype variables or enumerated 
type variables. 

Explanation 

For information on the semantics of a <simple variable declaration;^ refer to its definition 
in the ALGOL Programming Reference Manual, Volume 1: Basic Implementation and to 
the definition of the <scalar type declaration> in this section. 

STRUCTURE TYPE Declaration 

<structure type declaration> 

<scalar type declaration . 1 

— <set type declaration 

— <structure block type declaration — 
— connection block type declarations 

Explanation 

A <structure type declaration> defines a user-specified data type by associating a type 
definition with an identifier. 
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SCALAR TYPE Declaration 



<scalar type declaration> 



— TYPE 



■type identifier — = 



^enumerated type>- 
-<subtype> 



<type identifier> 

— <i denti f i er> 1 

Explanation 

A SCALAR TYPE declaration defines a user-specified data type by associating a type 
definition with a <type identifier>. The type identifier can then be used in contexts in 
which a data type must be specified, such as in declarations of variables, arrays, 
procedures, constants, and formal parameters. The type identifier can also be used in such 
contexts as declarations of array dimensions, other SCALAR TYPE declarations, and 
STRUCTURE TYPE VARIABLE declarations. 

The SCALAR TYPE declaration allows the creation of entirely new types and allows types 
to be defined in terms of the predefined types (REAL, INTEGER, and BOOLEAN) and 
types from previous SCALAR TYPE declarations. 

Two kinds of type definition are possible: enumerated types and subtypes. Each is 
discussed in this section under its own heading. 
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Enumerated Types 



<enumerated typo 



L ORDERED -I 



( — <enumerated literal list> — ) 



<enumerated literal list> 



^enumerated 1 i teral >- 




:nonnegative constant integer expression: 



<enumerated literal> 

— <i denti f i er> 1 

<nonnegative constant integer expression> 

A <constant integer expression> that evaluates to an integer greater than or equal 
to 0 (zero). 

Explanation 

An <enumerated type> declaration defines a new, bounded, discrete data type. An 
enumerated type is unordered by default, or it can be declared as an ORDERED 
enumerated type. 

The purpose of an enumerated type is to enable you to declare a data type that has a range 
of valid values that can be enumerated specifically. For example, valid values of an 
enumerated type called DEVICES might include DISKPACK, FLOPPY, GCRTAPE, and 
TERMINAL. 

Each <enumerated literal> in an enumerated type declaration has a unique nonnegative 
integer value associated with it. You can assign these associated values explicitly in the 
enumerated type declaration. Those enumerated literals to which you do not assign values 
are given associated values by the compiler. The associated values are considered to be 
constants of the enumerated type being declared, and the enumerated literals denote 
these constant values. 

The associated values assigned to the literals by the compiler are assigned to all the 
literals from left to right in ascending order; that is, the associated value assigned by the 
compiler is the associated value of the preceding literal incremented by one. When you do 
not assign a value to the first literal in the list, the compiler assigns it a value of 0 (zero). 

If you assign an associated value to a literal, the value must be exactly one greater than 
the associated value of the preceding literal. If the literal is the first in the list, the value 
must be 0 (zero) or greater. 
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The values of ordered enumerated types can be compared using the following relational 
operators: 



< 

LSS 

<= 

LEQ 



• EQL 

• NEQ 

• > 

• GTR 

• >= 

• GEQ 

If X and Y are two literals of an ordered enumerated type, then X is less than Y if and only 
if the value associated with X is arithmetically less than the value associated with Y. The 
other relations are similarly defined. 



Unordered enumerated types can be compared for equality and inequality only by the 
following operators: 



• EQL 



• NEQ 

No other relational operators are defined for unordered enumerated types. 



Example 

BEGIN 

TYPE COIN = ORDERED (NICKEL, DIME, QUARTER), 

BILL = ORDERED (TEN, TWENTY, FIFTY, HUNDRED), 

DAY = ORDERED (M0N=1, TUE, WED, THU, FRI, SAT, SUN), 

FLOWER = (JASMINE, LILY, ROSE); % UNORDERED 



COIN BIT, CHANGE; 
BILL WAD; 
FLOWER BOUQUET; 
BOOLEAN RELATION; 



INTEGER PROCEDURE H0URS_W0RKED (WORKINGDAY) ; 
VALUE WORKINGDAY; 
DAY WORKINGDAY; 
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BEGIN 



IF WORKINGDAY <= FRI THEN 

HOURS_WORKED:= 8 
ELSE 

HOURS_WORKED:= 0; 
END HOURS_WORKED; 

WAD: = FIFTY; 
BIT:= QUARTER; 
CHANGE:^ DIME; 
BOUQUET:= ROSE; 

WAD:= NICKEL; % SYNTAX ERROR 

RELATIONS TEN < TWENTY AND % TRUE 
NICKEL < DIME AND % TRUE 
DIME > QUARTER AND % FALSE 



RELATIONS BOUQUET = JASMINE; % FALSE 



LILY > ROSE; 



% SYNTAX ERROR 



RELATION: 



CHANGE < BIT; 



% TRUE 



END. 
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Subtypes 

<subtype> 

— SUBTYPE — <base type identifier>- 

<base type identifier> 

REAL 



- BOOLEAN 
-<subtype identifier>- 



<enumerated type identifier . — . 

enumerated subtype identifier— ' I— enumerated range> 

integer subtype identifier— ■ 

I— <integer subtype range> 

' — INTEGER -, 

I— <integer range> 



<enumerated range> 

— <enumerated endpoint> — .. — enumerated endpoint>- 
<enumerated endpoint> 



-<enumerated typed constant identifier>- 
-<enumerated 1 i teral > 



^constant scalar type expression> 

<integer subtype range> 

— <integer subtype endpoint> — .. — <integer subtype endpoint>- 



<integer subtype endpoint> 



-r-<number> r- 

<— <constant scalar type expression>— ' 



<integer range> 

— <integer endpoint> — .. — <integer endpoint>- 



<integer endpoint> 

— <number> 
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Explanation 

A <subtype> declaration defines a data type that takes its characteristics and valid 
operations from the <base type identifier>. In certain cases, the valid values for the 
subtype can be less than the valid values for the base type identifier. However, the range 
for the subtype being created cannot be larger than the valid range for the base type 
identifier. 

A subtype is not a new type; its type is the same as that of the base type identifier. When 
the base type identifier is a discrete, ordered type, the range of valid values can be limited 
by the inclusion of a range. The valid operators for a subtype are those allowed for the 
specified base type. 

The primary purpose of subtypes is to enable you to separate different types of data that 
might have similar fundamental characteristics. For example, a height and a weight are 
both numbers and they share a set of valid operators (addition, subtraction, and so on). 
However, height might be measured in inches, and weight might be measured in pounds. 
In this case, HEIGHT and WEIGHT could be declared as subtypes descended from 
INTEGER. In this way, the programmer informs the compiler that the two types are 
conceptually different, and the compiler must ensure that the types are not accidentally 
mixed. 

A range can be specified if the base type identifier is INTEGER, an ordered enumerated 
type, or a subtype of either of these two. The range endpoint specifications must be of the 
base type or of a direct ancestor of the base type. If a constant identifier is used as an 
<integer endpoint>, the constant must have been declared as an INTEGER CONSTANT. 

Example 

BEGIN 

TYPE MONEY = ORDERED (PENNY, NICKEL, DIME, QUARTER, 

DOLLAR, FIVEDOLLAR, TENDOLLAR) , 
COINS = SUBTYPE MONEY PENNY. .QUARTER, 
BILLS = SUBTYPE MONEY DOLLAR. .TENDOLLAR; 

TYPE T0TAL_M0NEY = SUBTYPE INTEGER, 

POCKET_CHANGE = SUBTYPE T0TAL_M0NEY 2.. 15; 

COINS YOUR_LARGEST, MY_LARGEST; 

T0TAL_M0NEY Y0UR_T0TAL, MY_T0TAL; 

POCKET_CHANGE YOUR_CHANGE, MY_CHANGE, TOTAL_CHANGE; 

YOUR_LARGEST:=QUARTER; 
MY_LARGEST:= DIME; 
YOUR_CHANGE:= 15; 
MY_CHANGE:= 7; 

TOTAL_CHANGE:= MY_CHANGE + YOUR_CHANGE; 
END. 
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Descendant Types 

An enumerated type is a completely new type, but a subtype descends from its base type. 
A base type can, in turn, descend from yet another type. This chain of ancestry can be 
followed all the way up to the root type, which is not descended from another type. The 
root type is either a predefined type (INTEGER, REAL, and BOOLEAN) or an enumerated 
type. A subtype is said to be a descendant type of its root type. 

Examples 

In the following examples, all of the types declared are descendant types of INTEGER. 



TYPE FIRST = SUBTYPE INTEGER, 

SECOND = SUBTYPE FIRST, 

THIRD = SUBTYPE SECOND; 

TYPE A = SUBTYPE THIRD; 



Assignment Compatibility 

Two types are said to be assignment compatible if a value of one type can be assigned 
directly to a variable of the other type. Among the scalar types, the following are the only 
cases of assignment compatibility: 

• A type is always assignment compatible with itself. 

• A subtype or typed constant is assignment compatible with any of its ancestor types. 

• A constant or enumerated literal is assignment compatible with its base type or with 
any descendant of its base type. 

If an assignment is to be made between two types that are not assignment compatible, 
explicit type conversion using the mapping function is necessary. For more information, 
see "MAPPING Function" in Section 5, "Expressions and Functions." 
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Range Checking 

By default, range checking is performed whenever there is a chance of assigning to a 
variable a value that is not defined for the type of that variable. 

No run-time range checking is performed on the simple assignment of types that are 
assignment compatible (that is, a direct assignment not involving any kind of expression). 
Therefore, it is possible for the <structure type identifier to assume a value that is 
outside its range without any interrupt occurring if the source of the assignment was 
never initialized. 

A range error is reported whenever a range check fails. Range errors can occur during 
expression evaluation or during an assignment operation. 

The manner in which range errors are reported depends on the target computer family for 
which the code is compiled. (See the discussion of the <target option> block directive in 
Section 7, "Compiler Controls.") If a range error occurs within code compiled for LEVEL1 
machines, a false assertion is reported. If a range error occurs within code compiled for 
LEVELO machines, a divide-by-zero fault is reported. 

The error message indicates only that the value is not in range; it does not indicate 
whether the value is too large or too small. 

Range checking can be disabled through the use of the block directive NORANGECHECK. 
Within a block for which range checking is disabled, range checking can be enabled 
through the use of the block directive RANGECHECK. 
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SET TYPE Declaration 

<set type declaration 

r* ' 1 

— TYPE — <set identifier — = — SET — ■ ■— <set base type>— 1 

I— OF —I 

<set identifier> 

— <i denti f i er> 1 

<set base typo 

<type identifier^ . 1 

— ( — enumerated literal list> — ) — 
L INTEGER 1 

Explanation 

A <set type declaration> defines a structured type for which the range of values is all 
possible subsets of the specified <set base type>. In mathematical terms, a <set identifier> 
defines the powerset of its set base type. A variable of set identifier type can contain any 
subset of the set, including the null set and the entire set. 

The ordinal numbers associated with the set base type must be within the range 0 through 
1000. 

When the set base type is a type identifier, then the type of the type identifier must be an 
enumerated type, a subtype descended from an enumerated type, or a subtype descended 
from INTEGER. 

When the set base type is an <enumerated literal list>, the enumerated literals must not 
have been declared previously. The literals are treated as unordered enumerated literals. If 
a<nonnegative constant integer expression> is present for the first <enumerated literal>, 
the expression must be a nonnegative number less than or equal to 1000. If the 
nonnegative constant integer expression is present for literals other than the first one in 
the list, the expression must be equal to one more than the value associated with the 
previous literal. 

When the set base type is INTEGER, the maximum possible range (0 through 1000) is 
assumed. An assignment to a set is allowed if the root type of the right-hand side and the 
left-hand side are the same. For example, INTEGER values or values with a type 
descended from INTEGER can be assigned to a set variable that has a set base type of 
INTEGER. 
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If the maximum value in the set is 47 or less, a single word is allocated for set variables of 
that set type. If the maximum value in the set is greater than 47, an array is allocated for 
set variables of that set type. As a result, set variable of a set type with a maximum value 
greater than 47 should not be used in places that cannot handle a p-bit. 



Example 

TYPE COLOR 
TYPE COLORSET 
TYPE MONEY 

TYPE COINS 
BILLS 

TYPE COINSET 
CARDSET 

WEIGHTS 



(RED, BLUE, GREEN, YELLOW); 
SET OF COLOR; 

ORDERED (PENNY, NICKEL, DIME, QUARTER, 

DOLLAR, FIVEDOLLAR, TENDOLLAR) ; 
SUBTYPE MONEY PENNY. .QUARTER, 
SUBTYPE MONEY DOLLAR. .TENDOLLAR; 
SET OF COINS, 

SET OF (CLUB = 2, DIAMOND, HEART = 4, 

SPADE) , 
SET OF INTEGER; 



STRUCTURE BLOCK TYPE Declaration 



<structure block type declaration> 



TYPE — <identifier>— = — STRUCTURE BLOCK 

FORWARD ; — 

BEGIN — declaration list>— END - 1 



A STRUCTURE BLOCK TYPE declaration provides a method of grouping together data 
(and procedures that act upon that data) into a logical unit and a method of enabling the 
data to persist past block exit of those procedures. 

Structure block variables and structure block arrays can be declared from the 
STRUCTURE BLOCK TYPE declaration. Refer to the ALGOL Programming Reference 
Manual, Volume 1 for details regarding structure block variables and structure block 
arrays. 

In NEWP, there are restrictions on what can be declared in the < declaration list>. You 
cannot declare SUPPLYs, LABELs, EXCEPTION PROCEDURES, EXPORTLIBRARYs, and 
INTRINSICs within a structure block. 

Constant, type, set, and literal identifiers are permitted outside the structure block. If the 
syntax requires a constant, then no side effects occur for the qualifier. For example, 
structure block activation does not occur. Defines can be invoked outside the structure 
block only when qualified by the structure block type identifier. 

Note: An EVENT or EVENT ARRAY element that is declared in the declaration list of a 
STRUCTURE BLOCK TYPE declaration cannot be used as the event part of a 
direct I/O statement unless the direct array involved is declared in the same 
structure block and both are elements of the same instance of that type. 
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When an inline procedure is declared inside an embedded structure block, the procedure 
cannot be referenced from outside the embedded structure block if the procedure makes 
reference to any identifiers declared in the outer structure block. The following example 
illustrates the restrictions: 



TYPE SB = STRUCTURE BLOCK 
BEGIN 
REAL R; 

TYPE SBINNER = STRUCTURE BLOCK 
BEGIN 
REAL X; 

PROCEDURE PJNLINE; 
BEGIN [INLINE] 
R := 88; 



END; 

PROCEDURE PJNLINE2; 
BEGIN [INLINE] 
SBINNER SBINVAR; 



:= 88; 



Illegal when P_INLINE is referenced from 
outside the SBINNER structure block 



% Illegal when P_INLINE2 is referenced from 
% outside the SBINNER structure block because 
% SBINNER is an item that belongs to the structure 
% block SB 



SBINVAR. X 
END; 
PROCEDURE P: 
BEGIN 

PJNLINE; % Legal 

PJNLINE2; % Legal 

END; 
END SBINNER; 

SBINNER SBINNERVAR; 

END SB; 
SB SBVAR; 

SB. SBINNER SBINREF; 

SBINREF := SBVAR. SBINNERVAR; 

SBINREF. PJNLINE; % 

% 

SBVAR. SBINNERVAR. PJNLINE; % 

% 

SBINREF. P INLINE2; % 



reference for PJNLINE 
reference for P INLINE2 



Error occurs because of reference to R 
in PJNLINE 

Error occurs because of reference to R 
in PJNLINE 

Error occurs because of reference to 

SBINNER in P INLINE2 
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STRUCTURE TYPE VARIABLE Declaration 

<structure type variable declaration> 



— <structure type identifier— L<identifier>— ' 1 

<structure type identifier> 

— I — <set identifier — i 1 

L-<type identifier— ' 

Explanation 

The <structure type variable declaration> defines variables of data types that have been 
declared previously in <structure type declarations. 

The initial value of a SET structure type variable is the null set. The initial value of a scalar 
type variable is undefined. 

The identifier declared in a structure type variable declaration is referred to in this 
document as a <set variable identifier>, <enumerated variable identifier;^ or 
<subtypevariable identifier;^ depending on the type of the declared variable. 

Example 

TYPE MONEY = ORDERED (PENNY, NICKEL, DIME, QUARTER, 

DOLLAR, FIVEDOLLAR, TENDOLLAR) ; 
TYPE COINS = SUBTYPE MONEY PENNY. .QUARTER; 
TYPE COINSET = SET OF COINS; 

COINSET POCKETCHANGE; % POCKETCHANGE is a <set variable identifier 

MONEY PAY; % PAY is an enumerated variable identifier 

COINS SPARECHANGE; % SPARECHANGE is a <subtype variable identifier 

SUPPLY Declaration 

<supply declaration> 

— SUPPLY i denti f i er>— 1 



Explanation 

The SUPPLY declaration allows a module nested within another module to supply the 
body of a procedure declared in the outer module. 

Each identifier must be that of a procedure that has been declared FORWARD, and that 
could have occurred at the same syntactic location as the module containing the SUPPLY 
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declaration. The specified procedures must occur within the module containing the 
SUPPLY declaration. 

Example 

MODULE PHYSICALIO; 

INTERFACE PHYSICALIOJNTERFACE (IOFINISH); 
MODULEEXPORT PHYSICALIOJNTERFACE; 
PROCEDURE IOFINISH (...);... FORWARD; 
BEGIN PHYSICALIO; 
MODULE CPIO; 

SUPPLY IOFINISH; 
BEGIN CPIO; 

PROCEDURE IOFINISH (...);... 

BEGIN 



END IOFINISH; 
END CPIO; 
END PHYSICALIO; 



3-60 



8600 2003-403 



Declarations 



VALUE ARRAY Declaration 

In addition to the VALUE ARRAY declarations permitted in ALGOL, NEWP allows the 
VALUE ARRAY declaration to be used to declare value arrays of a scalar type. The 
elements of a scalar type value array are specified by <constant scalar type expressions 
of the same type as the value array. 



String literals that are less than 48 bits long are left-justified and padded with zeros on the 
right to make them 48 bits long when they are used in the <constant list> of a <value array 
declaration>. Note that this practice differs from that of the ALGOL compiler, which right- 
justifies string literals less than 48 bits long when used in value arrays. If the type of the 
value array is DOUBLE, the low-order word is all zeros. 

For information related to this type of declaration, see "Scalar Type Expressions" in 
Section 5, "Expressions and Functions." 

WITH Declaration 

<with declaration> 

— WITH — structures list> 1 

<structures list> 



9 

-structure variable detail >- 



<structure variable detail> 

— — structure block variable identifier— . > 

— structure block type identifier 

— connection library identifier 

— <typed activation specifier 

L ( — <detail list>— ) -I ' 



<detail list> 



s 

1 ^ connect! on block item>— r 
I— structure block item> — ' 



<typed activation specifier> 

-<typed activation variable>- 



l — ^Ly(jeu L i vat i uii veil lauic r 

L-<typed activation expression>— ' 



<typed activation expression> 

— <typed activation designator— ■— AT — <identifier r- 

I— VIA — <word expression^ 

<typed activation designator> 



— ACTIVATION — OF — i— <structure block type identifier — r- 
L-<connection block type identifier— ' 
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<typed activation variablo 

An identifier that is associated with a typed activation. 
Explanation 

The WITH declaration establishes scope within which items of a structure block are 
visible and assumed to be prefixed by the specified structure block type identifier, 
structure block variable, structure block array element, or activation structure block 
reference. 

WITH used with a <structure block type identifier establishes scope only for non- 
addressable items of the specified structure block. Attempts to reference addressable 
items result in errors. 

WITH remains in effect for the entire block in which WITH appears. When WITH is 
specified in a module header, the declaration remains in effect for the entire module. 
WITH does not remain in effect when processing PENDING procedures. 

The evaluation of variables referenced by the <structure variable detail> is performed 
once during the time of block entry. However, for declarations in the MCP outer block, 
qualifiers are evaluated as each structure block item is encountered. In addition, structure 
block qualifiers for the MCP outer block must be unindexed and not formed from a VIA 
clause. 

No overshadowing of local or global variables is permitted. Local variables can 
overshadow WITH variables only when the local variables are declared following the 
WITH declaration. 

The WITH declaration affects all variables referenced by the <structure variable detail>. If 
a <detail list> is present, only those items specifically declared in the <detail list> are 
affected. 



Examples 



TYPE SBT = STRUCTURE BLOCK 
BEGIN 

REAL Z, I, J, X; 
END; 



SBT SBVAR; 

SBT REFERENCE SBREF; 
ACTIVATION OF SBT ASSIRW; 
REAL A; 



% Structure Block Variable. 
% Structure Block Reference. 
% Typed Activation. 



WITH SBVAR; 
WITH SBREF; 
WITH ASSIRW; 



% All items in SBT are included. 



WITH ACTIVATION OF SBT AT A; 
WITH SBVAR (I, J); % 



% Only I and J are included 
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The order of declarations can be important, as shown in the following example: 

WITH SBVAR; 
REAL J; 

J := 10; % The local J is used. 

The combination of declarations can also be important. The following example results in 
an error: 

REAL J; 
WITH SBVAR; 
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Statements 



NEWP provides several kinds of statements that are not supported by ALGOL. These 
NEWP-specific forms of statement are discussed in this section and in "Statements 
(UNSAFE)" in Section 8, "UNSAFE Mode." 

The following table briefly describes some of the differences in statements that are 
supported in both NEWP and ALGOL. More extensive differences in statements are 
described in the rest of this section. For information on ALGOL statements that are not 
supported in NEWP, refer to Appendix A, "ALGOL Features Not Implemented in NEWP." 

Statement NEWP Information 

ACCEPT Only the <pointer expression> form of the <accept 



statement> is supported. 



ASSIGNMENT 



For information on differences in all forms of the 
assignment statement;-, refer to "ASSIGNMENT Statement" 
later in this section. 



AWAITOPEN 



NEWP does not support the PARTICIPATE option in the 
<awaitopen options>. 



CASE 



NEWP does not allow a <string literal> to be used as an 
<arithmetic primary>. Numeric constants should be used 
instead. In addition, CASE labels in ALGOL are limited to the 
range 0 through 1023. NEWP does not have this restriction. 
However, in NEWP, the difference between the highest and 
lowest valued labels cannot exceed 1023. For example, if the 
smallest label is 100, the largest label can be no more than 



1123. 
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Statement NEWP Information 

CLOSE Like ALGOL, the NEWP compiler emits code to call the MCP 

for non-MCP programs that do not use the CLOSE statement 
as a function. In the MCP, no additional code is emitted; but 
at compile time a message is issued, which warns that the 
result is not handled. NEWP does not support the 
<associateddata option> in the <port close option>. In 
addition, NEWP does not support the REWIND clause of the 
<close option> for the CLOSE statement. Instead, NEWP 
provides a RETAIN clause for the CLOSE option, as shown in 
the following example: 



FOR 



CLOSE (<file designator^ RETAIN); 

In the <iteration part>, NEWP allows the STEP phrase to be 
omitted, even if an UNTIL clause is present. If you omit the 
STEP <arithmetic expression> phrase, a default of STEP 1 is 
assumed. 



FREEZE 



This statement has more options than are available in 
ALGOL. Refer to "FREEZE Statement" later in this section. 



GO TO 



NEWP does not allow branching into FOR loops or THRU 
loops. Note that branching within FOR and THRU loops is 
allowed, as long as you declare the label within the loop. 



I/O 



NEWP does not allow the <rewind statement> and <space 
statement> forms of the I/O statement. For more information, 
refer to Appendix A, "ALGOL Features Not Implemented in 
NEWP." 



MLSaccept 



NEWP does not support a <string variable> or subscripted 
string variable> as part of this statement. Use the <pointer 
expression> form of the statement. 



ON 



NEWP provides a declaration instead of a statement. Refer to 
"ON Declaration" in Section 3, "Declarations." 



OPEN 



Like ALGOL, the NEWP compiler generates code to call the 
MCP for non-MCP programs that do not use the OPEN 
statement as a function. In the MCP, no additional code is 
emitted; but at compile time a message is issued, which 
warns that the result is not handled. NEWP does not support 
the <associateddata option> in the <open options>. 
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Statement NEWP Information 

PROCEDURE NEWP does not support the following types of <actual 

INVOCATION parameters;.: 

• < string array designator > 

• <direct switch file identifier 

• < switch file identifier > 

• <format designator 

• <switch label identifier 

• <list designator > 

• < switch list identifier > 

• <picture identifier 



PROCESS In NEWP, the <process statement> is unsafe. Refer to 

"PROCESS Statement" in Section 8, "UNSAFE Mode," for 
information on the differences between NEWP and ALGOL. 

READ NEWP does not support several features that ALGOL allows. 

Note that all limitations mentioned here also apply to the 
NEWP WRITE statement. NEWP does not allow the <core-to- 
core part> of the file part. In addition, the <format and list 
part> cannot be a format designator, editing specification, 
asterisk (*), or <free field part>. The <format and list part> 
cannot include a string variable. The list cannot include an 
<iteration clause> that includes a WHILE loop embedded in a 
FOR loop. The update replacement construct (:=*) cannot be 
used on the variable of a FOR iteration clause. 



REPLACE 



There are a number of differences between ALGOL and 
NEWP <replace statement> syntax and semantics. Refer to 
"REPLACE Statement" later in this section and to "REPLACE 
Statement" in Section 8, "UNSAFE Mode." 



REPLACE 
POINTER- 
VALUED 
ATTRIBUTE 



Only the <simple source> form of this statement is supported 
in NEWP. If a pointer-valued attribute is to be replaced by the 
value of another pointer-valued attribute, replace the value 
into a temporary array, and then replace the destination 
attribute with the contents of the array. 



RESET 



The RESET statement has been renamed the RESETEVENT 
statement in NEWP. 



RESIZE NEWP does not support a <string array designator as a 

<special array resize parameter. However, NEWP does 
allow an interlock array to be resized, provided you do not 
specify DISCARD. 
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Statement 

SEEK 



NEWP Information 

NEWP allows the keyword SPACE to appear before the 
<arithmetic expressions This form of the SEEK statement is 
used to perform the function of the ALGOL <space 
statements-. 



SET 



SWAP 



The SET statement has been renamed the SETEVENT 
statement in NEWP to avoid conflicts with the data type SET. 

Refer to "SWAP Statement" later in this section for 
information on the differences between NEWP and ALGOL. 



WAIT 



WAITANDRESET 



WRITE 



NEWP does not require parentheses around the <time> 
specification as ALGOL does. NEWP does not support the 
form of the WAIT statement that includes no parameters 
(wait for interrupt). Refer to "WAIT Statement" in Section 8, 
"UNSAFE Mode," for information about unsafe options for 
the <wait statements 

NEWP does not require parentheses around the <time> 
specification as ALGOL does. Refer to "WAIT Statement" in 
Section 8, "UNSAFE Mode," for information about unsafe 
options for the <waitandreset statements 

Refer to the discussion of the <read statement> earlier in this 
table. 
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ASSIGNMENT Statement 

The ASSIGNMENT statement causes the item on the right-hand side of the assignment 
operator (:=) to be evaluated and the resulting value to be assigned to the item on the left- 
hand side of the assignment operator. 



Differences between ALGOL and NEWP ASSIGNMENT Statements 

The following are some differences between ALGOL and NEWP in regard to various kinds 
of ASSIGNMENT statements: 



• NEWP does not support the <complex assignment and <string assignment forms of 
the ASSIGNMENT statement. However, in NEWP, every string-valued library attribute 
is treated as a pointer-valued attribute. For more information, refer to "REPLACE 
Statement" later in this section. 

• NEWP allows a <partial word part> on the left-hand side of an <arithmetic update 
assignment, but ALGOL does not. 

• NEWP requires that parameters for attributes follow the attribute name (ALGOL 
requires that the parameters be placed before the attribute name). 

• NEWP allows a CONNECTION parameter as a library attribute designator, in addition 
to the options that ALGOL allows. 

The following is the NEWP syntax for the <arithmetic file attributes 
< arithmetic file attribute > 



— <file designator^ — . — <arithmetic-valued file attribute name>- 

"*n 1 

^attribute parameter specification^ 



<attribute parameter specification 



— ( — <attribute parameter list> — ) 



<attribute parameter list> 



r- COPY 

- ROW 

- STATION - 
L- SUBFILE - 1 



<arithmetic expression>- 
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The differences between the ALGOL and the NEWP syntax are shown in the following 
example: 

I :=DISKFILE(COPYNUM) .ERRORTYPE; % ALGOL syntax 

I:= DISKFILE. ERRORTYPE (C0PY=C0PYNUM) ; % NEWP syntax 

Data comm file attributes must include the phrase STATION- as part of the <attribute 
parameter specifications 

I:= TERMFILE(l) .WIDTH; % ALGOL syntax 

I :=TERMFILE.WIDTH(STATI0N=1) ; % NEWP syntax 

In addition, keywords are needed to identify some types of attribute parameters. For 
example, the ALGOL statement REPLACE MYFILE(l). TITLE BY PTR would be 
REPLACE MYFILE. TITLE (SUBFILE^ 1) BY PTR in NEWP. 

• NEWP does not allow the <arithmetic update assignment form (:=*) of the 
ASSIGNMENT statement to be used with file or task variables. 

• NEWP does not fully support the use of an <arithmetic type transfer variable> on the 
left-hand side of an <arithmetic assignments 

Activation Structure Block Reference Assignment 

<activation reference assignment> 

— <activation identifier — := > 

■*— r— <acti vation identifier . 1 

— <null value> 

— <connection library instance designator— 

— <structure block variable identifier 

— <structure block array element> 

— <structure block reference variable> 

— <this function> 

<activation identifier> 

The activation identifier is a variable defined by an ACTIVATION structure block 
reference variable declaration. 

An activation reference assignment associates an activation reference identifier with a 
particular activation structure block or connection block. Implicit type transfers or 
coercions allow activation references to be assigned from structure block variables or 
connection library references. The same coercions are applied to actual parameters. 
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Activation Type Transfer Variable 



<activation type transfer> 

— ACTIVATION — ( — i— <structure block variable identifier^ 
— <structure block reference variable> — 
<connection block reference variables 



The use of an activation type transfer variable causes the value of the activation skeleton 
SIRW for the specified structure block or connection library variable on the right-hand 
side assignment to be stored in the activation variable on the left-hand side. If the 
activation is typed, the types of the right-hand and left-hand sides must match. Untyped 
activations can not be assigned to a typed activation. 

Example 

TYPE SBT = STRUCTURE BLOCK 
BEGIN 
REAL R; 

DEFINE X = 5 #; 
END; 



SBT SBVAR; 

SBT REFERENCE SBREF; 



%Structure Block Variable 
%Structure Block Reference Variable 



ACTIVATION OF SBT ASSIRW; 
ACTIVATION NOTYPE; 



%Typed Activation 
%Untyped Activation 



ASSIRW := ACTIVATION(SBVAR) ; 
ASSIRW. R := 10; 



Array Reference Assignment 

Array reference assignment in NEWP is similar to that in ALGOL. The differences are as 
follows. 

In the ARRAY REFERENCE ASSIGNMENT statement, the corresponding dimension of the 
<array reference variable> and the <array designator must have the same type. 

In addition, the element size of the array designator must match that of the array reference 
variable. In the context of ARRAY REFERENCE ASSIGNMENT statements, subtypes and 
enumerated types are considered to have an element size of a single word. 
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Set Assignment 

Set assignment can be accomplished by assigning a <set expression> or a <set update 
expression> to a set variable. The <set variable identifier and the set expression or set 
update expression must be of compatible types. 

<set assignment> 

— <set variable identifier — := — ■— <set expression> . 1 

I— <set update expression^ 

<set expression> 

For information on <set expression;*, see Section 5, "Expressions and Functions." 
<set update expression> 

— * — <set operator>— i— [ — <variable ordinal > — ] — . 1 

I— <simple set expression> — - — < 



<set operator> 
<simple set expression> 
<variable ordinal> 

For information on these constructs, see Section 5, "Expressions and Functions." 
Example 

TYPE COLORSET = SET OF (RED, BLUE, GREEN, YELLOW); 
COLORSET C1,C2; 

Cl:= [RED, YELLOW]; % CI is assigned the set whose 

% members consist of the elements 
% "RED" and "YELLOW". 

C2:= * + [GREEN] ; % The element "GREEN" is added as a 

% member to the previous value of C2. 

Cl:= []; % CI is assigned the NULL set. 
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CASE Statement 



In addition to the ALGOL syntax for the CASE statement, NEWP allows extensions to 
<case head> and to <number list>. For more information on the CASE statement, see the 
ALGOL Programming Reference Manual, Volume 1: Basic Implementation. 

<case head> 

— CASE — <scalar type expression — OF 1 

<number list> 



— — l — ^constant scalar type expression— ■— : — 1 

L ELSE 1 

Explanation 

The <constant scalar type expressions in the number list must be assignment-compatible 
with the <scalar type expressions in the case head. 

NEWP is more strict than ALGOL in its handling of unnumbered CASE statements. If the 
last statement of a statement list is terminated with a semicolon, then an extra null 
statement is added to the list. Thus, if there are N statements in the list, the null statement 
makes it N+l statements, and the range of valid cases spans 0 through N+l. 




8600 2003-403 



4-9 



Statements 



FOR Statement 

In addition to the ALGOL syntax for the FOR statement, NEWP allows extensions to the 
<for statements the <initial part>, and the <iteration part>. For more information on the 
FOR statement, see the ALGOL Programming Reference Manual, Volume 1: Basic 
Implementation. 

<for statement> 



— FOR — <scalar type variable> — := — I— <for list el ement>— I— DO > 

-*-<statement> 1 

<initial part> 

— <scalar type expression> 1 

<iteration part> 

— STEP — i— <arithmetic expression> — UNTIL > 

I— <scalar type expression^ 

-*-<scalar type expression> 1 

Explanation 

When a <scalar type variable> is used in the FOR statement, the <scalar type 
expressions specified in the <for list element> part must be assignment-compatible with 
the scalar type variable. An exception to this is that an <arithmetic expression> that is not 
assignment-compatible can be used following the STEP clause. 

Example 

TYPE COLOR = ORDERED (RED, BLUE, GREEN, YELLOW); 
COLOR COLORVAR; 

FOR C0L0RVAR:= BLUE STEP 1 UNTIL YELLOW DO 
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FREEZE Statement 

<freeze statement> 



— FREEZE — ( -p- PERMANENT 
TEMPORARY 
MCP 



L CONTROL — , — <procedure identifier^ 



Explanation 

In addition to the values supported by ALGOL, the MCP option is allowed as a value for 
the parameter to the FREEZE statement. If you specify the MCP option, the compiler 
control option MCP must be set. 

Unlike the other forms of the FREEZE statement,FREEZE(MCP) is allowed in a block 
with no library EXPORT declarations. FREEZE(MCP) exports all entry points appearing in 
library EXPORT declaration that occur at D[0] up to the FREEZE statement in the 
symbolic. No subsequent library EXPORT declarations are allowed. 

The options TEMPORARY, PERMANENT, and CONTROL work exactly as they do in 
ALGOL. 

The <procedure identifier> required in the CONTROL form of the FREEZE statement must 
be a previously declared untyped procedure with no parameters. 

If a D[0] library EXPORT declaration is changed during a Separately Compiled Procedure 
(SEPCOMP), all procedures containing FREEZE(MCP) statements must be recompiled. 
For more information on SEPCOMP, refer to Section 6, "Compiling NEWP Programs." 
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REPLACE Statement 

NEWP does not support the SDIGITS (signed digits) clause of the <replace statements 
Instead, you can simply test the value that is being replaced and use the REPLACE 
statement to put in the appropriate sign. Then use the DIGITS clause to add the absolute 
value of the item. 

When an <arithmetic expression> appears as the <source part> in a REPLACE statement, 
and no FOR clause is included, exactly 48 or 96 bits of data (depending on whether the 
<arithmetic expression> is single-precision or double-precision) are transferred as 
characters. The size of the characters is determined by the destination part>. This differs 
from the ALGOL implementation in which either 6 or 8 characters are transferred. 

NEWP provides an extension to the <transfer part> of the REPLACE statement. The 
syntax for the extension to the transfer part is as follows: 

<transfer part> 

— FOR — <length> — WITH — <edit micros> 1 

<length> 

— arithmetic expression 1 

<edit micros> 

— INSERT — ( — <insert character> — ) 1 

<insert character> 

— <EBCDIC constant> 1 

The transfer part of the REPLACE statement has been extended to include the INSERT 
option. INSERT (<insert character>) translates and transfers <length> characters from the 
source string to successive character positions in the destination string. Each leading zero 
source character is replaced with an insert character; the remaining characters are 
transferred unchanged. 

The source and destination pointer expressions must denote 8-bit characters. 
Furthermore, the resulting destination string is undefined if the source string contains 
characters other than the EBCDIC digits 0 through 9. 

In NEWP, every <string-valued library attribute> (TITLE, FUNCTIONNAME, INTNAME, 
LIBPARAMETER, and INTERFACENAME) is treated as a <pointer-valued attribute >. As a 
result, the REPLACE statement is used to assign values to these attributes, rather than the 
<string assignment form of the ASSIGNMENT statement. 
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Example 

REPLACE LIBRARY1 . FUNCTIONNAME BY POINTERVAR; 
% NEWP setting of FUNCTIONNAME attribute for libraries 

REPLACE LIBRARY(LIBRARYl) .FUNCTIONNAME BY POINTERVAR; 
% NEWP setting of FUNCTIONNAME attribute for connection libraries 

LIBRARY1. FUNCTIONNAME: = STRINGVAR; 
% ALGOL setting of FUNCTIONNAME attribute for libraries 

It is required that the value contained in the array pointed to by the pointer variable must 
contain a termination character of period (".")• Therefore, the "." character cannot be part 
of the array value for LIBPARAMETER except as the terminating character. 

SELECT Statement 

<select statement> 

— SELECT — ( — alternative identifier — ) 1 

alternative identifier> 

— <i denti f i er> 1 

The SELECT statement initializes an alternative module, which includes the items you 
declare inside the alternative specified by the alternative identifier>. For more 
information, see "MODULE Declaration (Old)" in Section 3, "Declarations." 

A SELECT statement can occur only in an initialization procedure. Only one SELECT 
statement can be executed in an initialization procedure; an INVALID OPERATOR fault 
occurs if a second SELECT statement is executed. You must declare in the same module 
the initialization procedure and the alternative identifier it selects. 
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SWAP Statement 

The SWAP statement is implemented with the same syntax and semantics as in ALGOL, 
with the following exceptions: 

• The <complex variable>s are not supported by NEWP and therefore cannot appear in 
the SWAP statement. 

• The <enumerated variable identifiers and <subtype variable identifiers can be 

swapped as long as the variables on both sides of the swap operator (:=:) are of 
the same type. 
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Expressions and Functions 



NEWP provides several kinds of expressions and functions that are not supported by 
ALGOL. These NEWP-specific expressions and functions are discussed in this section and 
in "Expressions and Functions (UNSAFE)" in Section 8, "UNSAFE Mode." 

The following table describes some of the differences in expressions and functions that 
are supported in both NEWP and ALGOL. For information on ALGOL functions and 
expressions that are not supported in NEWP, refer to Appendix A, "ALGOL Features Not 
Implemented in NEWP." 



Expression or Function 



NEWP Information 



ARITHMETIC FUNCTION 
DESIGNATOR 



NEWP provides the <packdecimal functions-, 
which is not supported by ALGOL. For more 
information, refer to "PACKDECIMAL Function" 
later in this section. 



ARITHMETIC OPERATOR 



The keyword TIMES as a synonym for an 
asterisk (*), or multiplication sign, is not 
supported in NEWP. 



ARITHMETIC PRIMARY 



The NEWP definition of <arithmetic primary> is 
different from that in ALGOL. For the NEWP 
definition, refer to "Arithmetic Expressions" later 
in this section. 



BOOLEAN FUNCTION 
DESIGNATOR 



NEWP provides the Boolean <decimalconvert 
functions-, which is not supported by ALGOL. 
For more information, refer to 
"DECIMALCONVERT Function" later in this 
section. 



BOOLEAN OPERATOR 



The NEWP definition of <Boolean operator> is 
different from that in ALGOL. For more 
information, refer to "Boolean Expressions" later 
in this section. 



BOOLEAN PRIMARY 



The <complex relation> form of <Boolean 
primary> is not supported by NEWP. 
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Expression or Function 

CASE EXPRESSION 

CONDITIONAL EXPRESSION 



DESIGNATIONAL 
EXPRESSION 

DINTEGER FUNCTION 



EXPRESSION 



FUNCTION EXPRESSION 



INTEGER FUNCTION 



NEWP Information 

The <complex case expression> and 
<designational case expression> forms of the 
<case expression> are not supported in NEWP. 

The < conditional complex expression> and 
conditional designational expression> forms of 
<conditional expression> are not supported in 
NEWP. 

The only valid <designational expression> in 
NEWP is a <label identifier>. 

NEWP does not support the form of this function 
that accepts a <pointerexpression>. The 
DOUBLE function can be used instead. 

The <complex expression> form of 
<expression> is not supported in NEWP. 

The <complex function designator and <string 
function designator forms of the <function 
expression> are not supported in NEWP. 
However, NEWP supports <interlock function>s 
and <scalar type function>s, which are not 
supported by ALGOL. For more information, 
refer to "INTERLOCK Functions" and "SCALAR 
TYPE Functions" later in this section. 

In addition to the parameters accepted by the 
ALGOL <integer functions-, NEWP accepts the 
following as parameters: 

• <enumerated literal> 

• An expression of an enumerated type 

• An expression of a subtype that has an 
enumerated type or a root type of INTEGER 
or REAL 



ISVALID NEWP does not support <array identifier or 

<non-array data identifier as the argument to 
ISVALID. Also, NEWP does not support the 
READABLE or READ WRITE options for this 
function. NEWP supports <activation identifier 
for this function. 

LABEL DESIGNATOR The only valid <label designator in NEWP is a 

<label identifier. 
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Expression or Function 

LISTLOOKUP FUNCTION 



NEWP Information 

This function is unsafe in NEWP. Refer to 
Section 8, "UNSAFE Mode," for more 
information. 



NORMALIZE FUNCTION 



The syntax of the <normalize function> is 
identical to the ALGOL syntax, but the semantics 
are slightly different. NORMALIZE is an 
arithmetic-valued procedure that returns the 
result of the normalize (NORM) machine 
operator. If the parameter is single-precision, the 
result returned is of type REAL. If the parameter 
is double-precision, the result returned is of type 
DOUBLE. 



POINTER EXPRESSION 



Refer to "POINTER Expressions" later in this 
section. 



REAL FUNCTION 



SIZE FUNCTION 



STRING EXPRESSION 



THIS 



The <complex expression> is not supported as a 
parameter to the <real function> in NEWP. In 
addition to the other parameters supported by 
ALGOL, the NEWP REAL function accepts 
parameters listed earlier for <integer function> 
and a <string expression> as a parameter (see 
"String Expressions"). The function returns, as a 
REAL value, the bit image of the string 
expression. The bit image is right-justified with 
binary-zero fill. All bits in each character are 
used. The string expression cannot exceed 48 
bits in length. 

Following are examples of valid REAL functions: 

R:=REAL (48"04" & 8"NAME" & 48"00"); % NEWP 
R:=REAL (48"04D5C1D4C500);% ALGOL equiv. 

The <pointer identifier> is not supported as a 
parameter to the <size function> in NEWP. 

The definition of <string expression> is different 
in NEWP than it is in ALGOL. Refer to "String 
Expressions" later in this section. 

NEWP supports <activation identifier for this 
function. 



TRY EXPRESSION 



The <try complex expression> form of the TRY 
expression is not supported in NEWP. 
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Expression or Function 

USERDATA FUNCTION 



NEWP Information 

For the <outstuff parameter;*, the only single- 
precision simple variable accepted in NEWP is a 
REAL variable. For a subscripted array for the 
<instuff parameter>, NEWP does not generate a 
pointer expression. Instead, subscripted arrays 
are treated as arithmetic expressions. If an 
indexed data descriptor is needed for the instuff 
parameter, it must be specified explicitly when 
the instuff parameter is passed. For example, 
instead of passing ARAY[3] as the parameter, 
pass POINTER (ARAY[3],0) as the parameter. 



Arithmetic Expressions 



Arithmetic expressions in NEWP function just as in ALGOL, except for the specifics 
outlined as follows: 

<arithmetic expression> 



— I — <simpl e arithmetic expression 

L-<conditional arithmetic expression 
I— <try arithmetic expression 



<try arithmetic expression> 

— TRY — i— <try limited form> . 

I— <try arithmetic normal form>— ' 

<try arithmetic normal form> 

— arithmetic expression— L ELSE — arithmetic expression- 
arithmetic primary > 



t— <unsigned number> r 

— arithmetic concatenation expression> 

— arithmetic variable> — := — arithmetic expression>— 

— <arithmetic operand>— . 

L-<partial word part> 

— <numeric constant> 

— <constant identifier 



Unlike ALGOL, NEWP does not allow a <string literal> to be used as an <arithmetic 
primary>. However, you can achieve the same functionality by using a <numeric 
constants In addition, NEWP allows <constant identifier>s to be used as constant 
arithmetic primaries. 
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Note: In NEWP, an <arithmetic operand> can be <subtype variable identifier> 

descended from INTEGER or REAL in addition to any of the elements allowed 
in ALGOL. 

For more information on <arithmetic primary>, see the discussion of <constant 
identifiers-, <numeric constant>, and <structure type variable identifier in Section 3, 
"Declarations." 



Boolean Expressions 

<Boolean expression> 

— — <simple Boolean expression r 

— conditional Boolean expressions-— 
— <try Boolean expression> 

<try Boolean expression> 

— TRY — i— <try limited form> r- 

I— <try Boolean normal form>— ' 

<try Boolean normal form> 



— <Boolean expression>— ELSE — <Boolean expression>- 
<Boolean operator> 



T— AND r 

- OR 

- EQV 

- IMP 

— conditional operator>— 



<conditional operator> 



CAND -r 
COR — 
' — CIMP - 1 



<Boolean primary> 

In NEWP, a <set relation> is allowed as a <Boolean primary> in addition to those items 
allowed by ALGOL. 

<set relation> 



=simple set expressions 



EQL 
NEQ 



=simple set expression>- 



<variable ordinal: 



IN 



simple set expression> — 
variable set expression>- 
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<variable set expression> 

ri <set operator> 

— I— i— <set primary> 

I— <variable set constructor: 



Explanation 

NEWP includes conditional operators, which are similar to their 
corresponding standard Boolean operators. However, when a conditional 
operator is used, a second operand is not evaluated if the value of the 
first operand is sufficient to determine the value of the expression. The 
value returned is either 1 (TRUE) or 0 (FALSE) in the low-order bit of the 
resulting operand; the remaining 47 bits of the operand are undefined. The 
following table illustrates the functions of these conditional operators: 



Operands 

L R 

TRUE bool 

FALSE bool 

Operations 

L CAND R L COR R L CIMP R 

bool TRUE bool 

FALSE bool TRUE 



CAND has the same precedence as AND, while COR has the same precedence as OR, and 
CIMP has the same precedence as IMP. 

Following are examples of Boolean operators: 

B:= Rl NEQ 0 CAND R2/R1 EQL R3; 

B:= Rl GEQ 0 AND Rl LSS SIZE(A) COR R2 NEQ A[R1] ; 

B:= Rl GTR 0 CIMP A[R1-1] NEQ Rl; 
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Precedence in Boolean Expressions 

Occasionally, the precedence of terms within primary parts of expressions should be 
specified by parentheses. For example, when you use the <pointer table membership> 
primary, enclose it in parentheses whenever it is followed by a Boolean operator. In 
ALGOL, the following statement compiles: 

IF PTR_ID IN TRUTHJD FOR 1 AND BOOLEANJD THEN 

In NEWP, to get the statement to compile you need to change it as follows: 

IF (PTR_ID IN TRUTHJD FOR 1) AND BOOLEANJD THEN 



Set Relations 

There are two kinds of set relations; both return a Boolean value. The first compares the 
two simple set expressions for equality (= or EQL) or inequality ( A = or NEQ). The second 
determines whether or not the value of the specified <variable ordinal> is a member of (is 
IN) the set specified by the set expression. When simple set expressions are compared, 
they must be of compatible types. Equality or inequality is determined by doing a bit-by-bit 
comparison of two sets. Two sets of different lengths are considered equal if every bit that 
is set in one is also set in the other. 

Example 

TYPE COLOR = (RED, BLUE, GREEN, YELLOW, ORANGE); 

TYPE COLORSET = SET OF COLOR; 

COLORSET CSET1, CSET2, CSET3; 
BOOLEAN Bl, B2; 

CSET1:= [RED] + [BLUE] ; 

CSET2:= CSET1 * [YELLOW, BLUE, GREEN]; % CSET2 IS [BLUE] 
CSET1:= CSET1 - CSET2; % CSET1 IS [RED] 

CSET3:= UNIVERSE (COLOR); 

Bl:= CSET1 EQL [RED, BLUE]; % FALSE 

B2:= BLUE IN CSET2; % TRUE 
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Function Expressions 

<function expression> 

^arithmetic function designator 



-<Boolean function designator- 
-<pointer function designator- 



Arithmetic Function Designator 

<arithmetic function designator> 



procedure identifier 

arithmetic intrinsic name> — 
procedure reference variable^ 



L<actual parameter part>— ' 



Explanation 

The procedure specified by the procedure identifier, the procedure reference array 
element, or the procedure reference identifier must be of type INTEGER, REAL, DOUBLE, 
or of a subtype descended from INTEGER or REAL. 



Boolean Function Designator 

<Boolean function designator> 



-<procedure identifier 

-<Boolean intrinsic name> 

-<procedure reference variable>- 



actual parameter part 



Explanation 

The procedure specified by the procedure identifier, the procedure reference array 
element, or the procedure reference identifier must be of type BOOLEAN or of a subtype 
descended from BOOLEAN. 
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Null Value 

<null valuo 

— NULL 1 

You can use a null value to reinitialize procedure references, pointers, array references, or 
structure block references to null through the use of the 

• <activation reference assignment 

• <array reference assignment 

• <connection block reference assignment 

• <pointer assignment 

• <procedure reference assignment 

• <structure block reference assignment 

You can also use NULL as an actual parameter for 

• activation structure block reference parameters 

• arrays 

• call-by-value pointer parameters 

• connection block variable parameters 

• formal procedures 

• structure block variable parameters 

If a pointer or array reference variable contains NULL and an attempt to use that variable 
is made, a program interrupt occurs. If the procedure reference variable is invoked while 
it is NULL, a program interrupt occurs. 
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Pointer Expressions 

<pointer expression> 

<simple pointer expression 

— <conditional pointer expression>— 
— <try pointer expression> 

<try pointer expression> 

— TRY — <try pointer normal form> 



<try pointer normal form> 



— <pointer expression>— ELSE — <pointer expression>— 1 1 

Unlike ALGOL, NEWP does not allow a fully subscripted, noncharacter array that is used 
as a <pointer primary >. For example, the following program block compiles in ALGOL, but 
causes a syntax error on the REPLACE statement in NEWP: 



BEGIN 

ARRAY B[0:10] ; 

REPLACE B[0] BY 0 FOR 11 WORDS; 
END; 



An alternative is to use the POINTER type transfer function as follows: 



BEGIN 

ARRAY B[0:10]; 

REPLACE P0INTER(B[0]) BY 0 FOR 11 WORDS; 
END; 
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Scalar Type Expressions 

<scalar type expression> 

An expression that evaluates to a scalar type value. 
<simple scalar type expression> 

A <scalar type expression> that consists only of scalar type variables and scalar type 
constants. 

<constant scalar type expression> 

A <scalar type expression> that consists only of scalar type constants. 
Explanation 

The operands in a scalar type expression must have the same root type. The resulting type 
of the expression is based on the operation and the two operands. If all the operands are 
the same type, the resulting type of operations involving addition (+), subtraction (-), 
multiplication (*), MOD, and the Boolean operators is that of the operands. 

For those operations involving operands of different types and union, difference, 
intersection, MOD, and the Boolean operators, the resulting type is that of the common 
ancestor between the operands. An exception to this occurs when one of the operands is a 
constant. In this case, the resulting type is that of the nonconstant operand. For all other 
operations, the resulting type is INTEGER, REAL, or BOOLEAN, based on the type of 
operation. 

Enumerated types and subtypes descended from enumerated types are not allowed in 
arithmetic expressions. Exceptions to this are in the CASE and FOR statements. For more 
information on CASE and FOR statements, see Section 4, "Statements." 
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Set Expression 

<set expression> 



-<simple set expression>- 



I— <variable set constructor— ' 

<simple set expression> 

r<— <set operator—. 
— I— <set primary> ' 



<set operator> 



T:3 



<set primary> 



- ( — <simple set expression> — ) 

-<set variable identifier 

-<simple set constructor 



<simple set constructor 



[ 1 I <ordinal> ■— ] 

I— <range expression^ 
UNIVERSE — ( -r-<type identifier>-r- ) - 1 
!— <set identifier — < 



<ordinal> 



-<enumerated 1 i teral >- 
-<number> 



-<short enumerated variable identifier- 

-<short subtype variable identifier 

-<short scalar type expression> 
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<short enumerated variable identifier 
<short subtype variable identifier> 
<short scalar type expression> 

A variable or scalar expression for which the highest valid value is 47 or less, and for 
which the lowest valid value is 0 (zero) or greater. 

<range expression> 

— <ordinal> — .. — <ordinal> 1 

<variable set constructor 



— [ — 1 — i— <variable ordinal > . — ] 1 

I—Variable range expression^ 

<variable ordinal> 

<ordi nal > . 1 

— <integer variable> 

— <integer expression> 

— enumerated variable> 

— <subtype variable> 

— <scalar type expression>— 

<variable range expression> 

— i— <variable ordinal>— i— .. — i— <variable ordinal>— . 1 

I— <ordinal> ' I— <ordinal> ' 

Explanation 

A <set expression> generates a set. The <set operator>s perform the set operations of 
union (+), difference (-), and intersection (*). 

The operators can be applied to declared <set variable identifiers or to sets that are 
defined within the expression by the use of the <simple set constructor syntax (these 
sets are referred to as anonymous sets). The <set primary>s within a set expression must 
be of compatible types. 

A set constructor defines a value of an implied set type (an anonymous set). The members 
of the anonymous set are specified by the list of ordinal and range expressions, which 
must all be of the same type or subtypes of the same base types. 



8600 2003-403 



5-13 



Expressions and Functions 



The associated value of an enumerated literal cannot be used in place of the literal; 
integers can be used only when the base type of the set being constructed is INTEGER or 
a subtype of INTEGER. If a range expression is used, the base type must be a discrete, 
ordered data type; that is, an ordered enumerated type, INTEGER, or one of their 
descendant types. The members denoted are those values from the first ordinal through 
the second ordinal. If the second ordinal is less than the first ordinal, the range expression 
evaluates to the null set. 

The UNIVERSE function returns a set in which all possible members of the type indicated 
by the type identifier or set identifier are present. The type must be a discrete data type; 
that is, an enumerated type, a subtype of INTEGER, or one of their descendant types. 

The result of a set constructor takes its type from the elements used. In the case of the 
UNIVERSE function, it is the type of the type identifier or set identifier. Otherwise, the 
result is the type of the ordinals. An empty set constructor (that is, []) has no specific type 
and can be used in any set expression. 

If the MCP compiler option is set, <variable range expressions cannot be used in set 
expressions. 
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String Expressions 

<string expression> 



r<— <string concatenation operator>— . 
-I— <string primary> ' L 



<string concatenation operator> 

— r CAT n 

r !! _ 
L & 1 



<string primary> 



p<string constant^ r 

I— ( — <string expression> — ) — ' 



Explanation 

You can concatenate two or more string constants by using the <string concatenation 
operators The concatenation of two strings yields a new string whose length is the sum of 
the lengths of the two original strings. The value of the new string is formed by joining the 
second string immediately onto the end of the first string. 



Only <string constant>s of the same character type can be concatenated. For more 
information on string constants, see "String Constants" in Section 2, "Language 
Components." 



Examples of string expressions are as follows: 

"LONG STRING CONSTANT" 
"NUMBER" & 48"F1" 
47"3138"!! 7"ASCII CHARACTERS" 
"" CAT "DOESNT DO MUCH" 
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DECIMALCONVERT Function 

<decimalconvert function> 

— DECIMALCONVERT — ( — <operand to be converted— , > 

->-<number of digits> — , — <packed-decimal result> — ) 1 

<operand to be converted> 

— arithmetic expression> 1 

<number of digits> 

— <arithmetic expression> 1 

<packed-decimal result> 

— arithmetic variable> 1 



DECIMALCONVERT is a Boolean function that takes three arguments. 

• The first argument, V, is a single- or double-precision value that is to be converted to 
packed-decimal form. 

• The second argument, SF, specifies the number of packed-decimal digits to be 
converted. SF must be in the range 0 through 24. 

• The third argument, D, must be a variable of type REAL or DOUBLE. 

The remainder of V DIV 10**SF is returned by way of D as a left-justified, packed-decimal 
operand; if D is a double-precision value, the value returned is first extended to double 
precision. The function result is TRUE if the quotient V DIV 10**SF is nonzero; otherwise, 
the result is FALSE. The value returned in D can later be converted to a string of EBCDIC 
numeric characters by using the UNPACK intrinsic. 
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INTERLOCK Functions 

INTERLOCK functions use interlocks or interlock array elements to protect a resource 
that is shared between several participating processes. The use of these functions is 
similar to the use of an event with the PROCURE and LIBERATE statements except that 
interlock functions are often considerably faster than PROCURE and LIBERATE 
statements. The initial state of an interlock is FREE. For a complete list of the possible 
states of an interlock, refer to the "LOCKSTATUS Function" later in this section. 

ARROGATE Function 

<arrogate function> 

— ARROGATE — ( — interlock designator— ) 1 

<interlock designator> 

interlock identifier 1 1 

— interlock array identifier — [ — L<subscri pt> — ' — ] — 

The <arrogate function> claims the specified interlock for the caller, regardless of the 
previous state, but does not modify the contender list. At the completion of the 
ARROGATE function the interlock owner is the process that issued the ARROGATE 
function, and the state is either LOCKEDJJNCONTENDED or LOCKED_CONTENDED. 
The ARROGATE function is of type REAL, and the prior status of the interlock is returned 
as the result of an ARROGATE function. Refer to the "LOCKSTATUS Function" later in 
this section for the format of the result of the ARROGATE function. 

You can use this operation in several different circumstances. First, you can use it to 
"steal" the interlock. This might be desirable when you detect a correctable problem with 
the protected resource. A process can steal the interlock, correct the condition, and then 
return the interlock to normal use with the <unlock interlock function>. In this case, some 
action must be taken to notify or eliminate the process that held the interlock when the 
interlock was stolen. Otherwise, both the original owner and the new owner (after the 
interlock is returned to use) would believe that they were the owner. Because the 
contender list is not modified, an ARROGATE function should be used instead of a <break 
function> if the condition is correctable. 

You can also use the ARROGATE function to return a BROKEN interlock to normal use. 
You can accomplish this by issuing an ARROGATE function followed by an UNLOCK 
INTERLOCK function on an interlock whose state is BROKEN. 
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If the interlock is FREE when the ARROGATE function is issued, it becomes 
LOCKEDJJNCONTENDED. 

If the interlock is LOCKEDJJNCONTENDED or LOCKED_CONTENDED, the state 
remains unchanged, but the owner process identifier is changed to reflect the new owner. 

If the interlock is BROKEN, it becomes LOCKEDJJNCONTENDED. 

The ARROGATE function should be used primarily when you can determine that the entity 
protected by the interlock is temporarily corrupted or unavailable, but can be corrected. 
The ARROGATE function can be used to force acquisition of the interlock so that the 
condition can be corrected before any other contender is given access to the interlock 
(and the protected resource). 



Caution 

Few complications should arise if the lock is not held by any process when the 
ARROGATE function is used. Otherwise, extreme caution should be exercised. In 
many cases, it might be desirable to terminate the process that owned the lock. 
This action prevents the original owner from interfering with recovery efforts. 



Examples of ARROGATE functions are as follows: 
I:= ARROGATE (MYLOCK) 
ARROGATE (YOURLOCKS [3]) 
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BREAK Function 

<break function> 

— BREAK — ( — interlock designator^ — ) 1 

The <break function> is used to remove an interlock from normal use and to cause an 
error to be returned to all contenders for the interlock. This function is desirable if the 
resource that the interlock is protecting becomes permanently unavailable or hopelessly 
corrupted. You can use this function regardless of the state of the interlock at the time the 
operation is performed. 

When a BREAK function is executed, the state of the interlock is set to BROKEN, 
regardless of the prior state. In addition, any contenders waiting for the interlock receive 
an error result. The interlock is marked as owned by the process that issued the BREAK 
function. 

The BREAK function is of type REAL, and the prior status of the interlock is returned as 
the result of a BREAK function. Refer to the "LOCKSTATUS Function" for the format of 
the result of the BREAK function. 

The only way to return a BROKEN interlock to normal use is by using the ARROGATE 
function, followed by the UNLOCK INTERLOCK function. 

Refer to "ARROGATE Function" for information on temporarily removing an interlock 
from normal operation. You should use the BREAK function only if it is desirable to have 
all contenders return from the <lock interlock function> with an error. 



Caution 

Few complications should arise if the lock is not held by any process when the 
BREAK function is used. Otherwise, extreme caution should be exercised. In many 
cases, it might be desirable to terminate the process that owned the lock when 
the lock was broken. This action prevents the original owner from further 
corrupting the protected resource. 



Following are examples of the BREAK function: 
I:= BREAK (MYLOCK) 
I:= BREAK (YOURLOCKS [3]) 
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LOCK Function 



<lock function> 



— LOCK — ( — interlock designator^ 



:timeout> 

:event designator— 



) H 



<timeout> 

— <arithmetic expression> 1 

The <lock function> attempts to acquire the interlock. If you use the LOCK function as a 
statement, the process is discontinued when the result is not 1 (successfully acquired). 
The <timeout>, if present, specifies the amount of time the caller can wait if the interlock 
cannot be acquired immediately. The timeout is specified in seconds, and a value less than 
zero indicates that the program can wait indefinitely. If no timeout is supplied, a timeout 
of -1 is assumed. If the timeout is 0 (zero), the caller cannot wait, and the lock succeeds 
only if the interlock is FREE. 

If the interlock cannot be acquired immediately and an <event designator is present, the 
caller waits until either the interlock can be acquired or the event state is HAPPENED. 

The LOCK function is of type INTEGER, and the following values can be returned: 

Value Meaning 

1 The interlock was successfully acquired. 

2 The timeout elapsed or the event HAPPENED before the interlock 



could be acquired. 



4 



The interlock has a state of BROKEN and cannot be acquired. This 
occurs when the BREAK operation is used on the interlock. Refer to 
"BREAK Function" earlier in this section for more information on 
BROKEN interlocks. 
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The following conditions cause various values to be returned: 

• If the interlock has a state of FREE, it becomes LOCKEDJJNCONTENDED and a 
result of 1 is returned. 

• If the interlock is LOCKEDJJNCONTENDED, it becomes LOCKED_CONTENDED 
and the caller is placed in the contender list. When the owner unlocks the interlock, 
and the caller is at the head of the contender list, a result of 1 is returned. If the 
timeout expires before the caller can acquire the interlock, then a result of 2 is 
returned. 

Note: If the caller that timed out is the only contender, the interlock becomes 
LOCKEDJJNCONTENDED. 

If a BREAK operation is performed on the interlock while the caller is in the 
contender list, a result of 4 is returned. 

• If the interlock is LOCKED_CONTENDED, its state does not change, and the caller is 
added to the contender list. A result of 4 is returned. 

• If the interlock has a state of BROKEN, its state does not change, and a result of 4 is 
returned. 

Examples of the LOCK function are as follows: 
I:= LOCK (MYLOCK, 17) 
I:= LOCK (MYLOCKS [3]) 
LOCK (MYLOCK) 
LOCK (OURLOCKS [2], 4) 
I:= LOCK (MYLOCK, FINISHEVENT) ; 
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LOCKSTATUS Function 

<lockstatus function> 

— LOCKSTATUS — ( — interlock designator— ) 1 

The <lockstatus function> returns the status of the specified interlock. If the 
LOCKSTATUS function is used as a statement, a warning is issued at compile time, and no 
code is generated for the LOCKSTATUS. The LOCKSTATUS function is of type REAL, and 
the result has the following subfields: 

[47:24] Owner's process ID; 0 if none 
[23:22] Undefined 
[01:02] Current state: 

0 FREE 

1 LOCKEDJNCONTENDED 

2 L0CKED_C0NTENDED 

3 BROKEN 

The owner portion of the interlock status can be compared to the task attribute 
STACKNUMBER and the function PROCESSID. 

Examples of the LOCKSTATUS function are as follows: 

R:= LOCKSTATUS (MYLOCK); 

IF I:= LOCKSTATUS (Y0URL0CKS [3]). [47:24] = PROCESSID THEN 
G0F0RIT; 
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UNLOCK Function 

<unlock function> 

— UNLOCK — ( — interlock designator^— ) 1 

The <unlock function> is normally used to relinquish an interlock that was used earlier in 
a LOCK function. If the UNLOCK function is used as a statement, the process is 
discontinued when the result is not 1. The UNLOCK function is of type INTEGER, and the 
following values can be returned: 

Value Meaning 

1 The interlock was successfully unlocked. 

4 The interlock has a state of BROKEN and cannot be unlocked. Refer to 

"ARROGATE Function" for information on how to return a BROKEN 
interlock in normal operation. 

6 The interlock has a state of FREE and therefore cannot be unlocked. 



The following conditions cause various values to be returned: 

• If the interlock is FREE, the state is not changed and a result of 6 is returned. 

• If the interlock is LOCKEDJJNCONTENDED when this operation is performed, the 
state is changed to FREE and a result of 1 is returned. 

• If the interlock is LOCKED_CONTENDED, a result of 1 is returned, and the interlock 
is given to the first contender in the contender list. If there is only one contender in 
the list, the state is changed to LOCKEDJJNCONTENDED; otherwise, it is not 
changed. 

• If the interlock is BROKEN, the state is not changed and a result of 4 is returned. 
Examples of the UNLOCK function are as follows: 

I:= UNLOCK (MYLOCK) 

UNLOCK (YOURLOCKS [2]) 
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PACKDECIMAL Function 

— PACKDECIMAL — ( — arithmetic expression— , > 

->-<arithmetic expression> — ) 1 

PACKDECIMAL takes two arguments: a dividend V and a scale factor S. Each argument is 
first converted to an integer, if necessary. The resulting value of S must then be an integer 
in the range 0 through 12. PACKDECIMAL then returns a single-precision, left-justified, 
packed-decimal operand that represents the remainder of the following equation: 

V DIV 10**S 

The rightmost 12 -S digits are undefined. 



SCALAR TYPE Functions 

The following functions return scalar type values. The function value is undefined 
whenever any of its arguments has an undefined value. 



LOWER BOUND Function 

<lower bound function> 

— <type identifier— . — LBOUND 



The <type identifier> must denote one of the following discrete, ordered data types that 
has a defined lower bound: 

• Ordered enumerated types 

• Subtypes of ordered enumerated types 

• Subtypes of INTEGER that include a range specification 

For a subtype, the LOWER BOUND function returns the smallest value permitted in that 
type. For an ordered, enumerated type, this function returns the literal with the lowest 
associated value. The type of the function value is the same as the type identifier. 
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MAPPING Function 

<mapping function> 

— <type identifier — ( — <expression> — ) 1 

The MAPPING function is a type transfer function that changes the type of the 
<expression> to the type of the type identifier. Within the valid combinations given in the 
following paragraphs, if the value of the expression is not valid for the type identifier, the 
result of the MAPPING function is undefined. 

The expression provided as a parameter to the MAPPING function must evaluate to a 
value that is valid for the type identifier. The valid range for an enumerated type ranges 
from the numeric value associated with the first literal for the type to the numeric value 
associated with the last literal for the type. The valid range for a subtype is either specified 
with the declaration of the subtype or inherited from the parent type. 

If the expression is a numeric literal or a constant expression, the compiler issues an error 
when a range test violation is detected. If the expression involves the use of a variable, 
then run-time range checking occurs. 

Example 

As an example, assume the following declarations and assignments: 

TYPE COLOR = (RED=1, GREEN, BLUE, BLACK, WHITE, YELL0W=6) ; 

TYPE MONEY = ORDERED (PENNY=6, NICKEL, DIME, QUARTER, DOLLAR); 

TYPE COINS = SUBTYPE MONEY PENNY. .QUARTER; 

TYPE WEIGHTS = SUBTYPE INTEGER; 

TYPE LARGEWEIGHTS = SUBTYPE WEIGHTS 1000.. 10000; 

INTEGER I; 

COLOR MYFAV0RITE, Y0URFAV0RITE, THEIRFAVORITE; 
MONEY T0TALW0RTH, DESIREDW0RTH; 
COINS P0CKETCHANGE; 
WEIGHTS BABYWEIGHT; 
LARGEWEIGHTS HEAVY; 

I:= 2; 

MYFAV0RITE:= BLUE; 
Y0URFAV0RITE:= YELLOW; 
T0TALW0RTH:= DOLLAR; 
P0CKETCHANGE:= DIME; 
BABYWEIGHT:= 10; 
HEAVY := 1001; 
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In this particular case, the valid numeric ranges for the various types are as follows: 



Type 

COLOR 

MONEY 

COINS 

WEIGHTS 

LARGEWEIGHTS 



Valid Range 

1 through 6 

6 through 10 

6 through 9 

Range for INTEGERS 

1000 through 10000 



Given these valid ranges and the initial assignments shown in the previous example, the 
following uses of the MAPPING function all return valid results: 



THEIRFAV0RITE:= COLOR (3); 

THEIRFAV0RITE:= COLOR (PENNY); 
THEIRFAV0RITE:= COLOR (I); 
DESIREDW0RTH:= MONEY (YELLOW); 
DESIREDW0RTH:= MONEY (BABYWEIGHT); 

BABYWEIGHT:= WEIGHTS (COINS); 



THEIRFAVORITE gets BLUE = 3 
% 0k because PENNY = 6 = YELLOW 
% THEIRFAVORITE gets GREEN = 2 
% 0k because YELLOW = 6 = PENNY 
0k because BABYWEIGHT = 9 

which equals QUARTER 
COINS = DIME, which is 8 



The following assignments produce syntax errors because the compiler can detect that 
they all produce values outside the valid range for the type identifier in the MAPPING 
function: 



THEIRFAV0RITE:= COLOR (15); 

THEIRFAV0RITE:= COLOR (QUARTER) 



DESIREDW0RTH:= 
P0CKETCHANGE:= 



MONEY (GREEN); 
COINS (DOLLAR); 



THEIRFAVORITE:^ COLOR (HEAVY); 



Maximum COLOR is 6 

% QUARTER is a literal = 9; 
% too large for COLOR 

% GREEN =2; too small for MONEY 

% DOLLAR is a literal = 10; 
% too large for COINS 

% HEAVY is of type LARGEWEIGHTS, 
% and the valid range for COLOR 
% does not overlap the valid 
% range for LARGEWEIGHTS, so 
% a syntax error can be given. 



By contrast, the following assignment is valid but produces a run-time error because a 
variable, rather than a constant, is involved. In addition, the valid ranges of the types 
involved overlap: 



THEIRFAVORITE:^ COLOR (POCKETCHANGE) ; 



P0CKETCHANGE contains 
% DIME = 8; too large 
for COLOR 
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PREDECESSOR Function 

<predecessor function> 

— <type identifier — . — PRED — ( — <simple scalar type expression>^ 
+- ) 1 

The type identifier must denote a discrete, ordered data type. The type of the function 
value is the same as type identifier. 

If type identifier is a descendant type of INTEGER, then the <simple scalar type 
expression> must be an expression of type identifier. If the value of the expression is 
higher than the lowest value defined for that type (if any), the function returns the next 
lowest value of that type. This function is undefined if the value of the expression is less 
than or equal to the lowest value defined for that type (if any). 

If type identifier is an ordered enumerated type or a descendant of an ordered enumerated 
type, then the simple scalar type expression must be an enumerated literal of that type. If 
the literal does not denote the lowest associated value for that type, the function returns 
the next lowest associated value of that data type. This function is undefined for the literal 
with the lowest associated value. 

SUCCESSOR Function 

<successor function> 

— <type identifier — . — SUCC — ( — <simple scalar type expression>— > 
*- ) 1 

The type identifier must denote a discrete, ordered data type. The type of the function 
value is the same as type identifier. 

If type identifier is a descendant type of INTEGER, then the simple scalar type expression 
must be an expression of type identifier. If the value of the expression is less than the 
highest value defined for that type (if any), the function returns the next highest value of 
that type. This function is undefined if the value of the expression is higher than or equal 
to the highest value defined for that type (if any). 

If type identifier is an ordered enumerated type or a descendant of an ordered enumerated 
type, then the simple scalar type expression must be an enumerated literal of that type. If 
the literal does not denote the highest associated value for that type, the function returns 
the next highest associated value of that data type. This function is undefined for the 
literal with the highest associated value. 
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UPPER BOUND Function 

<upper bound function> 

— <type identifier^— . — UBOUND 1 

The type identifier must denote one of the following discrete, ordered data types that has 
a defined upper bound: 

• Ordered enumerated types 

• Subtypes of ordered enumerated types 

• Subtypes of INTEGER that include a range specification 

For a subtype, the UPPER BOUND function returns the largest value permitted in that 
type. For an ordered enumerated type, this function returns the literal with the highest 
associated value. The type of the function value is the same as type identifier. 
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Compiling NEWP Programs 



In NEWP, as in ALGOL, you can perform three kinds of compilations. The general term 
compile refers to any of these three types: 

• A full compilation, which parses all source lines and translates them into object code. 
This default compilation type occurs unless you set the control option MAKEHOST or 
SEPCOMP. 

• A host compilation, which is performed when you set the control option MAKEHOST. 
A host compilation is a superset of a full compilation. In addition to processing all 
source lines, it puts extra information in the code file that is necessary for the use of 
SEPCOMP. 

• A SEPCOMP compilation, which is performed when you set the control option 
SEPCOMP. A SEPCOMP compiles only the minimum necessary source lines, primarily 
those areas changed by a patch. The code and symbol files from a host compilation 
are used as the basis for a SEPCOMP. SEPCOMP is considerably faster than either a 
full compilation or a host compilation, but cannot be used in all cases. For further 
information on the limitations of SEPCOMP, see "SEPCOMP Guidelines" later in this 
section. 

This section provides information about all three types of compilations and states the 
rules for using each one. 

Note: The term host compile is often used as a general term for both full and host 

compilations. Because the host compilation takes longer and produces a larger 
code file, you should use a SEPCOMP or a full compilation whenever possible. 

For information about the input and output files for each type of compile, refer to the 
ALGOL Programming Reference Manual, Volume 1: Basic Implementation. 
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Full Compilations 

A full compilation is performed by default if you do not set the control options 
MAKEHOST or SEPCOMP. This type of compilation accepts one or more source files and, 
if there are no syntax errors, produces a code file. 

Host Compilations 

A host compilation is performed if you set the control option MAKEHOST. This type of 
compilation accepts one or more source files and, if there are no syntax errors, produces a 
code file that contains both the object code and the additional information that is 
necessary to do a SEPCOMP. This object code file is often referred to as a host file. 
Because of the inclusion of extra information, the code file produced by a host 
compilation is always larger than the code file produced by a full compilation. However, 
the actual object code produced is identical in both cases. 

The amount of information saved during a host compilation is under your control through 
the block directive SEPCOMPLEVEL. This block directive includes an integer that is the 
highest lexical level for which declaration information is stored in the host file. Each 
declaration for which this information exists can be separately compiled during a 
SEPCOMP. As a result, the value of the SEPCOMPLEVEL block directive during a host 
compilation determines the "granularity" of the separate compilation done during a 
SEPCOMP. A small value causes larger areas to be recompiled during a SEPCOMP, and a 
large value causes smaller areas to be recompiled. For more information about 
SEPCOMPLEVEL, refer to "SEPCOMP Background" in this section. 

One piece of information stored in a host file is the title of a symbolic associated with the 
compile. This information is required during a SEPCOMP and is determined as follows. 

If a new symbolic is being produced during the host compilation (that is, the control 
option NEW is set), the title of the symbolic is saved. Otherwise, if you set the MERGE 
option, the title associated with the TAPE file is saved because the bulk of the symbolic is 
usually found there. However, if you set neither the NEW option nor the MERGE option, 
the title associated with the CARD file is saved because that file contains the only input. 

Note: When the MERGE option is set, but the NEW option is not, the symbol file 

associated with the host is not complete, because it does not contain the changes 
made by the patch file (CARD). In this case, you should do one of two things 
when a SEPCOMP is performed with the host. You should either include the 
host-compiled patches with those to be compiled, or you should use the 
SEPCOMP merge capability. More information on both SEPCOMP and 
SEPCOMP merge is provided later in this section. 
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Compiling with SEPCOMP 

A SEPCOMP is performed when you set the SEPCOMP control option. This type of 
compilation requires at least three input files: a patch, a base symbol file, and the host file 
(object) from a previous host compile or SEPCOMP. The result is a complete code file, 
produced by taking a copy of the host file and changing only the sections modified by the 
patch. The base symbol file is necessary to allow the recompilation of the source code that 
was changed. 

Performing a SEPCOMP is not difficult, and it offers significant savings in time when 
compared to full and host compiles. However, some types of changes cannot be compiled 
with SEPCOMP, and you should become familiar with the rules of SEPCOMP to ensure a 
reliable result. For information on these rules, see "SEPCOMP Guidelines" later in this 
section. 

SEPCOMP is implemented by the NEWP compiler itself and does not require invocation of 
BINDER, as it does in ALGOL. 

Note: The object file produced by a NEWP SEPCOMP is a host file; another SEPCOMP 
can be done against it. However, the object code contained in the file might not 
be identical to the object code that would have been produced by a full or host 
compile. 

Certain types of syntax errors cannot be detected by a SEPCOMP because of the limited 
nature of the compilation. Although these errors are unusual, they do occasionally occur. 
In addition, if the guidelines listed under "SEPCOMP Guidelines" are not followed, a full or 
host compile and a SEPCOMP can produce code files that are different. These problems 
can be avoided by following the guidelines. 

Because of the limited compilation that is done during a SEPCOMP, certain other control 
options cannot be used. For example, neither a new symbol file ($NEW) nor xref files 
($XREF) can be produced by a SEPCOMP. Both these options require that all the source 
input be processed; therefore, these options have no meaning during a SEPCOMP. 

The user compiler control options that had a TRUE value when the host file was created 
are preserved and reinstated during a SEPCOMP. The VERSION option supplied for the 
host is also reinstated. 

As mentioned earlier, it is possible to use the output from one SEPCOMP as a host file for 
another one. The title of the default symbolic file is updated, as previously described for 
host compiles. Because there is not a symbol file that matches the host file exactly, you 
should read the information on the NEWP SEPCOMP merge capability later in this section 
before using the output of a SEPCOMP as a host file. 
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SEPCOMP Background 

The NEWP SEPCOMP facility is based on the concept of a region, which is a section of the 
program that can be separately compiled. Any change within a region causes the entire 
region to be recompiled. The size of a region is determined by the value of the 
SEPCOMPLEVEL block directive during a host compile. 

The executable statements of the outer block are always a region. In addition, a 
declaration list (for example, REAL A,B,C;), a procedure heading, and a procedure body 
can be regions, depending on their lexical level and the value of the SEPCOMPLEVEL 
block directive. 

An easy way to understand what is and is not a region is to consider the lexical level 
portion of the address of an item. If the lexical level is less than or equal to the 
SEPCOMPLEVEL, then the declaration is a region. Otherwise, the item is part of some 
other region. 

For example, if a declaration in the outer block of a non-MCP program is REAL A,B;, then 
A and B are assigned the addresses (2,x) and (2,x+l) respectively. Therefore, this 
declaration list is a region if SEPCOMPLEVEL is 2 or higher. On the other hand, if the 
same declaration appeared inside a procedure, the Program Control Word (PCW) of the 
procedure would be at (2,x), but A and B would be at lexical level 3 (for example, 3,x). If 
the SEPCOMPLEVEL is 2, the procedure would be a region, and the declaration of A and B 
would simply be part of that region. Any change to the declaration of A and B causes a 
recompilation of the entire region (the procedure). 

The default value of SEPCOMPLEVEL is 2 when the MCP control option is not set; the 
default value is 0 (zero) when the MCP option is set. 

NEWP records the starting and ending sequence numbers of each region. A declaration list 
begins on the line where the type (REAL, BOOLEAN, and so forth) is stated, and includes 
everything up to the semicolon (;). A procedure heading region begins on the line where 
the keyword PROCEDURE appears, and includes all the parameter declarations. A 
procedure body begins on the line where the BEGIN appears, and includes everything 
until the procedure END statement. 

In some cases, the recompilation of one region causes the recompilation of another 
region, even though the regions can be compiled separately. For example, if a declaration 
in a procedure is changed, the body of the procedure is also recompiled because the stack 
building code for the declarations needs to be regenerated. This recompilation occurs 
even when the nested declaration is at or below the lexical level specified by the 
SEPCOMPLEVEL block directive. The determination of that which needs to be recompiled 
is therefore based primarily on the patch and the SEPCOMPLEVEL, but is also affected by 
the relationships between regions. 
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During SEPCOMP, if the LIST compiler control option is set, this option causes a source 
listing to be generated for every patched region. Since any given area of a program can be 
made up of a number of regions, a complete listing of the area occurs only if every region 
in the area is changed. For example, at or below the lexical level specified by the 
SEPCOMPLEVEL block directive, a procedure heading and the body of the procedure are 
two different regions. If a SET LIST is placed before the start of the procedure declaration 
and if a POP LIST is placed after the end of the procedure, then a complete listing is 
obtained only if both the heading and the body are changed. To get a listing of the 
procedure body, you must put the SET LIST just after the procedure BEGIN and the POP 
LIST just before the procedure END. 

The level of the SEPCOMP information is stored in the host file. This level determines the 
contents and format of the SEPCOMP information. The level of the SEPCOMP information 
produced during the host compile must match the level of the information expected by the 
compiler doing the SEPCOMP. Since it is periodically necessary to improve the SEPCOMP 
information, not all combinations of host file, patch, and compiler succeed. If such a 
mismatch occurs, an error message is issued to indicate the mismatch and provide more 
information to resolve the error. In general, there are two choices: use the same version of 
the compiler for the SEPCOMP that was used for the host compile, or recompile the host 
with the compiler that will be used for the SEPCOMP. 

Performing a SEPCOMP 

Performing a SEPCOMP consists of providing the necessary input files and ensuring that 
the SEPCOMP option is set. The compiler can supply default titles for all of the required 
files, but ordinarily you supply the actual titles. Although SEPCOMPs can be performed 
from Command and Edit (CANDE), they are generally started from Work Flow Language 
(WFL) instead. Therefore, WFL examples are used here. For further information on the 
WFL programs, see the Work Flow Language (WFL) Programming Reference Manual. 

The internal names for the three required input files are as follows: 

Internal Name Input File 

CARD The patch file. 

TAPE or The name of the base symbolic associated with the host file. 

SOURCE 

HOST The name of the host file (the object). The host file must be 

compatible with NEWP. 



If you do not supply names, the compiler uses the names CARD and HOST for the patch 
and host file respectively. If the name of the base symbolic has been file-equated to 
SOURCE or TAPE, then that name is used. Otherwise, the base symbolic file name is taken 
from the host file, where it is stored during the creation of the host. 
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As an example, assume that the following program has been compiled to produce a host 
file (the object) and a base symbolic: 



100 


$ SET MAKEH0ST 


200 


$ SET NEW "SYMB0L/MYPR0GRAM 


300 


BEGIN [SEPCOMPLEVEL = 2] 


400 




500 


REAL X, Y, Z; 


600 




700 


PROCEDURE P; 


800 


BEGIN 


900 


BOOLEAN B; 


1000 


X:= Y * Z; 


1100 


IF X EQL 7 THEN 


1200 


B:= TRUE 


1300 


ELSE 


1400 


B:= FALSE; 


1500 


END P; 


1600 


Y:= 12; 


1700 


Z:= 14; 


1800 


P; 


2000 


END; % OF PROGRAM 



The compilation of this program produces both a host file named SYSTEM/MYPROGRAM 
and a new base symbolic file named SYMBOL/MYPROGRAM. The name of the new 
symbolic is stored in the host file, along with information about all the regions that occur 
at lexical level 2 and below. 

If a program patch is developed that includes $ SET SEPCOMP and is named 
MYPROGRAM/PATCH, the following WFL deck can be used to do a SEPCOMP: 

BEGIN JOB SEPCOMP; 
TASK T; 

COMPILE SYSTEM/MYPR0GRAM/SEPC0MPED WITH NEWP [T] LIBRARY; 

NEWP FILE CARD (KIND = DISK, TITLE = MYPROGRAM/PATCH); 

NEWP FILE HOST (TITLE = SYSTEM/MYPROGRAM); 
END JOB; 

Because the deck does not file-equate a TAPE file title, the default title 
SYMBOL/MYPROGRAM stored in the host file is used. The output is a host file named 
SYSTEM/MYPROGRAM/SEPCOMPED that is a copy of the original host file 
(SYSTEM/MYPROGRAM), except in those areas changed by the patch. 

Note that it is possible to supply the name of the host file with the SEPCOMP option. In 
that case, the patch could include the following card and the file equation to the file HOST 
in the WFL deck could be dropped: 

$ SET SEPCOMP "SYSTEM/MYPROGRAM" 

A host file title provided this way has precedence over any file equation to the HOST file. 
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SEPCOMP Guidelines 

Though SEPCOMP can be very useful, it does have some limitations. Certain types of 
changes can be compiled only with a full or host compilation. Other kinds of changes can 
be compiled with SEPCOMP, but require extra attention. Note that these restrictions only 
apply to changes at or below the SEPCOMPLEVEL. Any changes above this level are 
completely recompiled; therefore, the restrictions have no impact. 

The following types of changes at or below the SEPCOMPLEVEL cannot be compiled with 
SEPCOMP; a full or host compilation must be done: 

• Changes to library entry points. 

• The addition of executable statements in front of the first executable statement in a 
region. 

• Reordering of declaration regions. 

• Modification of a TYPE declaration. 

• Modification of the beginning or ending sequence numbers of a region. You can 
change the text on the beginning and ending lines of a region as long as the change 
follows the other rules listed here. 

• Modification or addition of multiple regions on the same line (for example REAL A; 
BOOLEAN B). 

• Modification of the type of a region (for example, REAL X,Y is changed to BOOLEAN 
X,Y). 

• Deletion of a module. 

• Addition of any text between adjacent modules (members of the same group of 
modules). 

• The setting of the INLINE block directive; you cannot change a regular procedure to 
an in-line procedure, or vice versa, during a SEPCOMP. 

• Within STRUCTURE or CONNECTION BLOCK TYPE declarations, only the contents 
of a procedure declared inside the structure or connection block can be changed. 
Changes to any of the declarations inside the structure or connection block are not 
allowed. 

• Deletion of a STRUCTURE or CONNECTION BLOCK TYPE declaration. 

Note: If the patch being compiled with SEPCOMP includes changes to an area that are 
not omitted in the host, testing cannot be completed until the patch is compiled 
with SEPCOMP and tested against another host in which that area was 
included. Note that during SEPCOMP, a warning is issued if the patch includes 
changes to omitted areas. 
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During a SEPCOMP, NEWP reads the xref files for the HOST and uses any that are present 
to recompile references to any changed or deleted declarations. 

To accomplish this, the compiler automatically looks for the following files: 

XREFFILES/<hostname>/REFS 
XREFFILES/<hostname>/DECS 

If present, they are used to ensure that all references to changed and deleted declarations 
are recompiled. If they are not present, you must follow the rules listed for changes at or 
below the SEPCOMP level. 

When a patch to a declaration is encountered and the xref files are loaded, the old 
declaration is compared to the new declaration. If the declaration has changed enough to 
invalidate the references to the original declaration, the xref files are used to mark the 
referenced lines. Each of these lines is then recompiled. Some types of variables are not 
yet supported in this implementation. These include format variables, type variables, type 
declarations, translate tables, truthsets, files, and items in an export or interface list. When 
the xref files are loaded and one of these declarations is changed, a warning that the xref 
files were not used is generated, and the old SEPCOMP rules, shown in the following 
guidelines, apply. 

The following guidelines must be observed if the designated types of changes occur at or 
below the SEPCOMP level and the xref files are not available. In most cases, you are 
responsible for ensuring that specific areas are recompiled. One way to accomplish this is 
to use the Editor command CHANGE to mark the specified lines as changed, even if no 
actual change was made. Another method is to include a $% card in each region that needs 
recompilation. 

• If an identifier is deleted, you must ensure that all references to it are also deleted. If 
all references are not deleted, a run-time error occurs when the code for the undeleted 
reference is executed. 

• If the type of an identifier is changed, or its declaration is moved from one region to 
another, you must ensure that all references to the identifier are recompiled. If this is 
not done, the host file will contain sections of code that handle the variable according 
to the old type as well as code that generates code based on the new type. 

• If the declaration of any of the following types of items is changed, you must ensure 
that all references to the identifier are recompiled. If this guideline is not followed, the 
resulting code file will not execute as expected, because some areas will use the old 
definition of the item and some will use the new. 

- Value array 
Array bounds 

- Constant 

- Define 

- File 

- In-line procedure 
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- Translate table 

- Truthset 

• In the MCP, if a D[0] library EXPORT declaration is changed, you must ensure that all 
procedures containing a FREEZE(MCP) statement are recompiled. 

SEPCOMP MERGE 

NEWP provides a capability known as SEPCOMP MERGE that allows a SEPCOMP to be 
done, even when no complete symbolic exists. The need for SEPCOMP MERGE could 
arise in two different instances. 

First, if a new symbol file is not created during the host compile, and a patch was included 
in the compilation, then no symbol file exists that includes the patch. 

Second, since a new symbol file cannot be created during a SEPCOMP, using the results of 
a SEPCOMP as the host file for a later SEPCOMP leads to the same problem: no symbol 
file exists that includes the patch originally compiled with SEPCOMP. 

SEPCOMP MERGE is very similar to SEPCOMP, except that it creates a virtual symbol. 
You provide two patch files: one patch that is used only to create a virtual symbol, and one 
normal SEPCOMP patch that is used to determine which regions are to be recompiled. 
Note that the virtual symbol patch does not need to be compiled, since it is already part of 
the host file. 

The SEPCOMP MERGE capability saves time because there is no need to compile over 
and over again patches previously compiled with SEPCOMP. It is particularly useful when 
several patches are developed that patch the same area. Each one can be compiled in turn 
with SEPCOMP and then can be used to create the virtual symbol when the next patch is 
compiled with SEPCOMP. 

The following WFL deck assumes that a second patch named MYPROGRAM/PATCH/2 is 
developed for the example program discussed earlier. The second patch includes the card 
$ SET SEPCOMPMERGE. 

BEGIN JOB SEPCOMPMERGE; 
TASK T; 

COMPILE SYSTEM/MYPROGRAM/SEPMERGED WITH NEWP [T] LIBRARY; 

NEWP FILE CARD (KIND = DISK, TITLE = MYPROGRAM/PATCH/2); 

NEWP FILE SOURCEP (TITLE = MYPROGRAM/PATCH) ; 

NEWP FILE HOST (TITLE = SYSTEM/MYPROGRAM/SEPCOMPED) ; 
END JOB; 

Because no title is equated for the TAPE file (base symbolic), the title stored in the host 
file is used as the default. The actual patch (CARD file) is applied against the base 
symbolic updated with the virtual source patch. 
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The SOURCEP file is the patch that is applied first to the base symbolic to obtain the 
virtual source. The title of this file can be provided as part of the control option, if desired. 
In that case, the second patch should include the following and the file equation to the 
SOURCEP file can be dropped from the WFL deck: 

$ SET SEPCOMPMERGE "MYPROGRAM/PATCH" 

A file title provided in this way has precedence over any file equation to the SOURCEP 
file. 

The SEPCOMP MERGE capability is subject to the same rules and guidelines listed earlier 
for SEPCOMP. 

Compiling for Syntax Only 

WFL provides an option that can be used with some compilers to check only the syntax of 
a source program. However, NEWP does the same work during a syntax compilation as it 
does for any other type of compilation. The only difference is that the object file is 
removed just before the compilation terminates. Therefore, there is no point in setting this 
option in a NEWP compilation. For more information on compiling for syntax, see the 
Work Flow Language (WFL) Programming Reference Manual. 
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Compiler Control Options 

Compiler control options in NEWP are similar in format and function to compiler control 
options in ALGOL. A list of ALGOL compiler control options not recognized in NEWP can 
be found in Appendix A, "ALGOL Features Not Implemented in NEWP." Any compiler 
control option item not listed in this section can be used as a user-control option. Option 
expressions are evaluated from right to left, unless parentheses are used to force a 
particular evaluation order. The following features differ from those in ALGOL: 

• The specification of an option without including SET, RESET, or POP causes no 
action other than setting that option. Standard options are not reset. For example, 
$MERGE does not reset LIST. The CLEAR option, as shown in the following example, 
can be used to reset all standard options: 



$ MERGE % IN NEWP HAS THE SAME EFFECT AS: 

$ SET MERGE % IN ALGOL OR NEWP 

$ CLEAR MERGE % IN NEWP HAS THE SAME EFFECT AS: 

$ MERGE % IN ALGOL 



• The dollar sign ($) must appear in column 1, 2, or 3. 

• The simple TADS option and other compiler-provided Boolean options are recognized 
as <option primary>s for use in option expressions. The following expression with the 
use of AND sets the user option TADSLIST by including the current values of the 
compiler options TADS and LIST: 



$SET TADSLIST = TADS AND LIST 
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The ALGOL definition of <option primary> is extended as follows: 
<option primary> 



- NOT 



-<user option> 

-<Boolean option> 

— <simple TADS option>- 
-<TRUE> 



<FALSE>- 

* 



— ( — <option expressi on> — ) — 



ALGOL Options Duplicated in NEWP 

The following compiler control options are implemented in NEWP exactly as they are in 
ALGOL: 

• ASCII 

• CODE 

• DELETE 

• ERRLIST, ERRORLIMIT, ERRORLIST 

• INCLNEW, INCLSEQ, INCLUDE 

• LIMIT, LINEINFO, LISTDOLLAR, LISTINCL, LISTOMITTED, LISTP 

• MAP 

• NEWSEQERR 

• NOBINDINFO 

• OMIT 

• PAGE 

• SEGS, SEQ, SEQUENCE, <sequence base>, <sequence increment> 

• SHARING, STACK, STRINGS 

• TARGET 

• TIME 

• <user option> 

• VOIDT 

• WARNSUPR 
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Additional NEWP Options 

The following options either are in ALGOL but are different in NEWP or are not in ALGOL 
and have been added to NEWP. 

ASD 

— ASD 1 



(Type: BOOLEAN, Default: FALSE) 

This option is meaningful only if you set the MCP or STANDALONE option. If you set the 
ASD option, the code that is produced should be used only on a machine capable of 
supporting Master Control Program/Advanced Systems (MCP/AS). If you also set the MCP 
option, but not the ASD option, the resulting MCP can be used only on a non-ASD system. 
This condition is enforced when an attempt is made to change MCPs using the CM system 
command. 

If you set both the ASD and STANDALONE options, the code can be used only on a 
machine capable of supporting MCP/AS. The memory image that the compilation produces 
in this case is tailored for ASD systems. 

When the compiler control option ASD is set, memory access uses the Absolute Store 
Reference Word (ASRW). This setting builds the ASRW for stand-alone programs. 

This option can appear only before the first source statement. 

CLEAR 

— CLEAR 1 



(Type: IMMEDIATE) 

The CLEAR option resets all compiler-provided options that can be set. 

INCLLIST 

— INCLLIST 



(Type: BOOLEAN, Default: FALSE) 

This option is a synonym in NEWP for the LISTINCL option. 
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INSTALLATION 



— INSTALLATION 



L773 



-<numeric constant>- 



1 <numeric constant— 1 



(Type: BOOLEAN, Default: FALSE) 

When TRUE, the INSTALLATION option causes the compiler to recognize a group of 
installation intrinsics so that they can be referred to in a NEWP program. 

The <numeric constant> must be an unsigned integer from 1 through 2047. The first 
numeric constant must be less than the second numeric constant. Numbers larger than 
2047 are treated as if they were equal to 2047. Numbers less than 1 are treated as if they 
were equal to 1. 



(Type: BOOLEAN, Default: FALSE for compiles originated in CANDE; TRUE otherwise) 

The LIST option in NEWP is identical to the LIST option in ALGOL except that NEWP 
allows you to specify a file name, which is used to set the TITLE attribute of the file LINE 
of the compiler. The <file name> must not include embedded quotation marks ("). 



— LISTO 1 

(Type: BOOLEAN, Default: FALSE) 

If LISTO is TRUE, all records from the secondary input file (TAPE) that are voided or 
replaced and all records from the primary input file (CARD) that are omitted are printed. 



LIST 



— LIST 



3 



— <file name> — 



LISTO 
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LIST1 



— LISTl -, r- 

L- 11 — <file name>— " - 1 



(Type: BOOLEAN, Default: FALSE) 

If LISTl is TRUE, a listing is produced during the first pass that the compiler makes while 
it is compiling module headings. The LISTl option allows you to specify a file name, which 
is used to set the TITLE attribute of the file LINE1 of the compiler. The <file name> must 
not contain any embedded quotation marks ("). 



MAKEHOST 

— MAKEHOST 



(Type: BOOLEAN, Default: FALSE) 

The MAKEHOST option in NEWP is similar to the MAKEHOST option in ALGOL. It must 
be set before the first source statement. This option controls the collection of information 
necessary for a SEPCOMP. When this option is set, compilation takes longer and produces 
a larger code file than when it is reset. Therefore, the MAKEHOST option should be set 
only when the result of the compilation is to be used as input to a later SEPCOMP. 

For more information about the use of this option and about SEPCOMP, refer to Section 6, 
"Compiling NEWP Programs." 

MCP 



— MCP 



(Type: BOOLEAN, Default: FALSE) 

The MCP option indicates whether the program being compiled is an MCP. If the MCP 
option is TRUE, the compiler allocates the segment dictionary and global variables at 
lexical level 0. Also, the code file generated when this option is TRUE contains a bootstrap 
in segment zero. 

This option can appear only before the first source statement. 
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MERGE 



— MERGE -, r- 

L- 11 — <file name>— " - 1 



(Type: BOOLEAN, Default: FALSE) 

The MERGE option in NEWP is identical to the MERGE option in ALGOL except that 
NEWP allows you to specify a file name, which is used to set the TITLE attribute of the 
file SOURCE of the compiler. The <file name> must not include embedded quotation 
marks ("). 



MODSTRICT 

— MODSTRICT 



(Type: BOOLEAN, Default: FALSE) 

Setting the MODSTRICT option disables the automatic import of interfaces or user- 
defined types and values. The MODSTRICT option can be set only before the first source 
statement. This option controls automatic import of interfaces into module bodies when 
the interfaces were explicitly imported into the corresponding module head. The option 
also controls the automatic import of user-defined types and enumerated values into a 
module when only a variable or the user-defined type itself was explicitly placed into the 
interface. 



NEW 



— NEW -, r- 

I— " — <file name> — " — ' 



(Type: BOOLEAN, Default: FALSE) 

The NEW option in NEWP is identical to the NEW option in ALGOL except that NEWP 
allows you to specify a file name, which is used to set the TITLE attribute of the file 
NEWSOURCE of the compiler. The <file name> must not include embedded quotation 
marks ("). 
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NOCOUNT 

— NOCOUNT 1 

(Type: BOOLEAN, Default: FALSE) 

The NOCOUNT option is used to control the accounting of statistical information when 
the STATISTICS option is TRUE. If NOCOUNT is TRUE at the end of the compilation of a 
procedure, the compiler emits code to cause the statistics handlers not to add the 
accumulated time for the execution of that procedure into the accumulated time for the 
procedure that called it. 

This option applies only to MCP gathering statistics. 

PROCREF 

— PROCREF 1 

(Type: BOOLEAN, Default: FALSE) 

If PROCREF is TRUE, each source record that references a procedure is listed with the 
line number of the declaration of that procedure. If the procedure body has not yet been 
compiled, the line number of the FORWARD declaration of the procedure is listed, 
preceded by an F. If LIST is FALSE, the setting of PROCREF is ignored. 

READLOCK 

— READLOCK 1 

(Type: BOOLEAN, Default: FALSE) 

The READLOCK option affects the operation of the BUZZ and BUZZ47 intrinsics. These 
intrinsics perform the multi-processor locking function by exchanging a data value with 
the value contained in the variable specified in the intrinsic invocation. The program uses 
the RDLK operator to perform the exchange, and the data value that is exchanged with the 
contents of the lock variable is generated by the intrinsic. It is this data value that is 
controlled by the READLOCK compiler control option. 

The exchange of this data value with the contents of the lock variable is repeated 
continuously until the value returned from the variable has a zero in bit 0 or bit 47, 
depending on whether the BUZZ or BUZZ47 intrinsic was invoked. At that point, the value 
stored in the lock variable is the data value generated by the intrinsic. 
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The data value generated by these intrinsics always contains a one in bit 0 and also 
contains a one in bit 47 if BUZZ47 is invoked. When the READLOCK option is FALSE (the 
default case), the remaining bits of the data value are zero. When the READLOCK option is 
TRUE, the remaining bits of the data value include additional information designed to aid 
in diagnosing locking problems. This information contains the stack number (SNR) of the 
stack that locked, or attempted to lock, the lock, as well as the segment dictionary index 
(SDI) and program word index (PWI) of the location in the program code that invoked the 
BUZZ intrinsic. This information is formatted as follows: 



0 
0~ 



0 



0 



0 



STACK 
NUMBER 



G 
A 
R 
N 

H 

I 



SDI 



G 
A 
R 
N 

L 

0 



PWI 



LOCK 
BIT 



Figure 7-1. Diagnostic Information Format 



The following is an explanation of the fields and bits of the word: 
Field or Bit Contents 

Stack number This field contains the value of the Stack Number Register (SNR), 
right justified. 

GARN This field contains the Global Activation Record Name (GARN). 

The GARN specifies the multiple MCP Dl activation records that 
contain the code segment descriptor to which the SDI field 
refers. This 6-bit name is split into two 3-bit fields. The high-order 
3-bit field is in the GARN HI field, and the low-order 3-bit field is 
in the GARN LO field. 

SDI and PWI These fields contain the Segment Dictionary Index (SDI) of the 
code segment and the Program Word Index (PWI) of the first 
operator of the BUZZ intrinsic code, respectively. Note that the 
low-order bit of the PWI field has been truncated to allow space 
for the lock bit. 



Lock bit 



This bit is a constant 1 and indicates the state of the hard lock. 
The location and use of this bit is identical to previous 
implementations. 



In addition, when the READLOCK option is TRUE, the original contents of the lock 
variable are retained in a stack cell for the duration of the BUZZ intrinsic. This practice 
permits you to determine the stack and the code that either owned or was competing for 
the lock when the current process initially attempted to lock it. 
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When the READLOCK and/or READLOCKTIMEOUT MCP compile time options are set, 
diagnostic information is placed in the word used when performing a BUZZ task on a lock. 



READLOCKTIMEOUT 

— READLOCKTIMEOUT 



(Type: BOOLEAN, Default: FALSE) 

If READLOCKTIMEOUT is TRUE, the MCP procedure READLOCKTIMEOUT is called 
whenever the BUZZ or BUZZ47 intrinsic returns the contents of the variable specified in 
the BUZZ intrinsic with the tested bit (bit 0 or bit 47, respectively) equal to 1. If the option 
is FALSE, the BUZZ intrinsic loops internally. 



SEPCOMP 



— SEPCOMP -, r- 

L- " — <file name>— " - 1 



(Type: BOOLEAN, Default: FALSE) 

The SEPCOMP option allows you to use the separate compilation capability, thus reducing 
the amount of time required to compile. This option must be set before the first source 
statement. You can specify a file name, which is used to set the TITLE attribute of the 
HOST file. The <file name> cannot include embedded quotation marks ("). 

For more information about the use of this option, refer to Section 6, "Compiling NEWP 
Programs." 



SEPCOMPMERGE 



— SEPCOMPMERGE -, r 

L- " — <file name>— " - 1 



(Type: BOOLEAN, Default: FALSE) 

The SEPCOMPMERGE option allows you to use an extended form of the separate 
compilation capability. This option should be used when no symbol file exists that exactly 
matches the host file. You can specify a file name, which is used to set the TITLE attribute 
of the SOURCEP file. The <file name> cannot include embedded quotation marks ("). 

For more information about the use of this option and about the SOURCEP file, refer to 
Section 6, "Compiling NEWP Programs." 
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SINGLE 



— SINGLE 



(Type: BOOLEAN, Default: TRUE) 

The <single option> causes the printout of a listing to be single-spaced. When the <single 
option> is FALSE, the printout is double-spaced. 



STANDALONE 

— STANDALONE 



77 



r- BETA 

- BETAINTERLEAVED 

- ASDX 

L- DELTA 



(Type: VALUE, Default: NONE) 



STANDALONE is used to specify that a stand-alone memory image is to be generated 
when the program is compiled. An example of a program requiring a stand-alone memory 
image is SYSTEM/LOADER. To take effect, this option must be assigned a value prior to 
the beginning of the program, and the MCP compiler control option must be TRUE. When 
the MCP option is TRUE, the OUTERBLOCK segment descriptor is placed at segment (0,5) 
by default (that is, unless overridden by a SEGMENT block directive). If STANDALONE is 
set to BETA or BETAINTERLEAVED, the Actual Segment Descriptor (ASD) or Actual 
Segment Descriptor Extended (ASDX) should also be set. Otherwise, the resulting 
program cannot be executed. 

The STANDALONE option causes the compiler to prepare a complete memory image of 
the program so that the program is ready to run when loaded into the system (starting at 
memory location zero). The maximum size of this memory image is 22,000 words. 

The STANDALONE option implicitly resets the LINEINFO option. If the LINEINFO option 
is subsequently set, an additional code file with a suffix of /LISTCODE is generated. This 
file can be used by the Editor in conjunction with its LOAD CODE, GO RCW, WHERE 
RCW, and LISTCODE commands. 

When STANDALONE is used by itself and is not assigned a value, STANDALONE assumes 
the value BETA if the ASD option is set. All other values must be specified explicitly. 

When STANDALONE is set to DELTA, the TARGET option must be set to LEVEL5. 

For all settings of STANDALONE the compiler sets ASD equal to TRUE. The compiler 
setting of ASD overrides the user's setting of ASD. This relationship avoids the 
nonexecutable code files being generated by incompatible settings for the two options. 
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Depending on the value that is assigned to STANDALONE, different memory images and 
code files are generated. The following items are common to all variants in the memory 
image: 

• The D[0] stack image 

• All code segments 

• All value arrays 

• All pool data items (for example, translate tables and truthsets) 

• The storage space for all SAVE arrays declared at a D[0] location 

• The proper entry PCW for the outer block at location (0,3) 

• A memory descriptor at location (0,4) 

The memory image does not include allocated data storage for any array declared within a 
procedure or any D[0] array not declared to be either VALUE or SAVE. No errors or 
warnings are given for these conditions, as it is assumed that you will provide a proper 
presence-bit handling routine. No memory links are provided to separate any of the 
allocated storage areas. 

Depending on the value that is assigned to STANDALONE, the code file and memory 
image generated by the NEWP compiler differ substantially. 

• If STANDALONE is set to BETA, the code file format is as follows: 

- A valid SEGO is in code segment 0. 

- An ASD table starts in code segment 1. The table is formatted as contiguous 
vectors of ASD1, ASD2, and ASD3. Following the ASD table is the memory image. 

- The SEG0[1].[23:4] (MCP/stand-alone type) field contains a 1, indicating an ASD 
code file that uses a 3-word linear ASD table. 

• If STANDALONE is set to BETAINTERLEAVED, the code file format is the same as 
that for BETA, except for the following: 

- The ASD or ASDX table starts in code segment 1. The table is formatted as 
interleaved vectors of ASD1, ASD2, ASD3, and ASD4, so that all ASD or ASDX 
table elements for a given entry are contiguous rather than all ASD or ASDX 
entries for a given element being contiguous. 

- The stand-alone stack contains not only all D[0] variables, but also a correctly 
formatted Dl frame with a Return Control Word (RCW) at the beginning of the 
outer block on top of the stack. The Dl frame contains a properly formatted and 
entered Dl Mark Stack Control Word (MSCW), a dummy RCW, and two words of 
zero before the RCW. The Top of Stack Control Word (TOSC W) at the base of the 
stack points at the RCW and the Dl MSCW. 

- The SEGO [ 1 ] . [23:4] (MCP/stand-alone type) field contains a 2, indicating an ASD 
or ASDX code file that uses a 4-word interleaved ASD or ASDX table. 
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• If STANDALONE is set to ASDX, the code file format is the same as for the 
BETAINTERLEAVED option, except for the following: 

- All word formats found in the STANDALONE code file meet the MCP/AS 
(Extended) specifications. 

- The TOSCW and copy TOSCW in the base of the stand-alone stack contain an 
MCP/AS (Extended) TOSCW word with the number 1 (SNR) in the [46:15] field. 

- The stand-alone stack contains not only all the D[0] variables but also a correctly 
formatted Dl frame and D2 frame. The Dl frame contains an entered Dl MSCW 
and a dummy RCW. The D2 frame contains an entered D2 MSCW, an RCW that 
points to the code stream to be executed, and an FCW on top of the stack. 

- The SEG0[1].[23:4] (MCP/stand-alone type) field contains a 3, indicating a MCP/AS 
(Extended) code file that meets all requirements for the code file to run on an 
ASDX system. 

The code file does not contain any SEPCOMP information, BINDINFO, or LINEINFO. For 
information on BINDINFO and LINEINFO, see the ALGOL Programming Reference 
Manual, Volume 1: Basic Implementation. 

If the STACK option is TRUE, the STANDALONE option prints a table of the code segment 
descriptors and data descriptors in the D[0] location, indicating which ones remain absent 
and showing the memory locations of the ones made present. Additionally, if 
STANDALONE is set to BETA, BETAINTERLEAVED, or ASDX, the ASD table is printed to 
indicate which ASDs are in use and to indicate their contents. 

Note: STANDALONE = BETAINTERLEAVED must be used on the A 17 system. 
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STATISTICS 



— STATISTICS 



( 



, ,— r LABELS -p- 1 - ) 

-SET L_ PBITS — 1 

L- RESET - 1 



(Type: BOOLEAN, Default: FALSE) 

When the MCP option is FALSE, the STATISTICS option functions exactly as it does in 
ALGOL, with the following exceptions: 

• When the STATISTICS option is TRUE, the NOBINDINFO option is assigned the value 
TRUE. A warning is given. 

• When the STATISTICS option is TRUE, the MAKEHOST option is assigned the value 
FALSE. A warning is given. 

• When the TADS option is TRUE, the STATISTICS option cannot be assigned the value 
TRUE. A warning is given. 

• Statistics are not generated separately for in-line procedures, but are included with 
the normal statistics gathering for the procedures in which they are invoked. 

When the MCP option and the STATISTICS option are TRUE, the code to accumulate MCP 
statistics is added to each procedure entry, exit, and invocation. The code consists of calls 
on procedures at fixed address couples; these procedures accumulate the statistical 
information and must be declared in the MCP. Calls on the statistics procedures are also 
emitted at the entry and exit of each block in which the block directive STATSUMMARY 
appears. 

The LABELS and PBITS options do not apply to MCP statistics and are therefore ignored 
when the MCP control option is set. 

The STATSUMMARY block directive applies to MCP gathering statistics only. 
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TADS 



— <simple TADS option> 



/1\- FREQUENCY 



L/i\_ 



/1\- REMOTE — <file identifier 



<simple TADS option> 

— TADS 



(Type: BOOLEAN, Default: FALSE) 

When the TADS option is set, special debugging code and tables are generated as part of 
the object code file. The use of the TADS option is incompatible with the use of certain 
other options, including MCP, SEPCOMP, and STATISTICS. 



Caution 

Use caution when you run the TADS option on a program that contains UNSAFE 
blocks. Avoid stepping through or executing breakpoints in unsafe 
CONTROLSTATE blocks, as this can cause the running program to lose 
CONTROLSTATE. 



The semantics for this option are the same as for ALGOL, with the exception that the 
TADS option is supported only for ALGOL type constructs in NEWP. 



UNDERLINE 



— UNDERLINE 



(Type: BOOLEAN, Default: FALSE) 

If UNDERLINE is TRUE, all procedure names in procedure declarations are underlined on 
the output listing. The setting of the UNDERLINE option is ignored if the LIST option is 
FALSE. 
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VERSION 

— VERSION — <release number> — . — <cycle number> — . > 

-*-<patch number> 1 

(Type: VALUE, Default: 00.000.000) 

The <version option> enables you to specify a version number for a source program or to 
replace an existing version number. Each occurrence of the <version option> in the CARD 
file updates the value of the version number. A warning is issued if the new version 
number is lower than the old version number. 

If the current value of the version number is 00.000.000, the version number is set to the 
value specified by the <version option>. Otherwise, the occurrence of the <version 
option> is updated with the current value of the version number. 

The updated record then replaces the original SOURCE record in the NEWSOURCE file (if 
the <new option> is TRUE) and in the program listing (if the control option LISTDOLLAR 
is TRUE or if the compiler control record begins in column 2 or 3). A warning is issued if 
the current value of version number is lower than the value originally specified by the 
<version option>. 

Note: All occurrences of <version option> in INCLUDE files are ignored. 

Unpredictable results occur if you attempt to specify a version number that 
exceeds 99.999.9999. 

During a compilation, the current value of each component of the version number can be 
accessed through the arithmetic functions COMPILETIME(20), COMPILETIME(21), and 
COMPILETIME(22), which return the release, cycle, and patch numbers, respectively. 

VOID 

— VOID 1 

(Type: BOOLEAN, Default: FALSE) 

If the <void option> is TRUE, all input other than compiler control records from the 
SOURCE and CARD files is ignored by the compiler until the VOID option is disabled. The 
ignored input is neither listed nor included in the updated symbolic file, regardless of the 
values of the <list option> and the <new option>. Once the VOID option is set to TRUE, it 
can be recalled using RESET or POP in a compiler control record in either the SOURCE or 
CARD file. 
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XREF 

— XREF 



(Type: BOOLEAN, Default: FALSE) 

Cross-reference generation is performed by the NEWP compiler itself and is controlled by 
two compiler options, XREF and XREFFILES. If XREF is TRUE, a cross-reference listing 
is produced (the listing is written to the file XREFLINE). If XREFFILES is TRUE, cross- 
reference files are generated. These options can be set or reset independently of each 
other. 

Alternatives within modules are cross-referenced in the same manner as modules are 
cross-referenced. If a procedure has its FORWARD declaration within a module — but 
outside any alternatives— and its actual body is in each alternative, each alternative 
procedure body is cross-referenced as an alias of each of the other alternative procedure 
bodies. 

Summary information, including the number of references and sort times, is printed if 
either XREF or both XREFFILES and TIME are set. 

XREFFILES 

— XREFFILES 1 



(Type: BOOLEAN, Default: FALSE) 

XREFFILES controls the generation of cross-reference information in disk file form. For 
more information, see "XREF" earlier in this section. 

$ 

- $ 1 

(Type: BOOLEAN, Default: FALSE) 

If both the LIST option and the $ option are TRUE, the printer listing includes all compiler 
control options. If the LIST option is TRUE but the $ option is FALSE, only compiler 
control records with an initial dollar sign ($) in any column from 2 through 72 appear in 
the printer listing. If the LIST option is FALSE, the value of the $ option is ignored. The $ 
option can appear only in columns 4 through 72, inclusive. The control option 
LISTDOLLAR is the preferred synonym for the $ control option. 
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Block Directives 



ASDSPACE — = 
CONTROLSTATE 
FIRSTFREEDOCELL — 
FIRSTSEGDESC — = - 

INHERITSTATE 

INLINE 



=integer> 



— <i nteger>- 
=i nteger> 



- MEMIMAGEBOUND — 

- NORANGECHECK 

- NORMALSTATE 

- PROTECTED 

- RANGECHECK 

- SAFE 

- SEGMENT 



=i nteger>- 



— = — <procedure identifier>- 

— = — <segment identifier — 

— = — <integer> 

- SEGMENTLEVEL — = — <integer> 

- SEPCOMPLEVEL — = — <integer> 

- STATSUMMARY 



<target option> 

>— UNSAFE — ( — <construct>- 



) 



<construct> 



— ( - 1 — r DESCRIPTOR 
FORK 



MACHINEOPS 

MEMORY 

MISC 



REFERENCE — 
REGISTERS - 
UPLEVEL — 
WORD 



Explanation 

Through the use of block directives, you can control segmentation, the use of potentially 
dangerous constructs, and other compilation concerns. Block directives can occur inside 
brackets immediately after any BEGIN statement. In the following discussion, the word 
block is used for the concept of block or procedure. 

In general, block directives are inherited by nested blocks unless overridden by block 
directives appearing in the nested blocks. However, CONTROLSTATE is inherited only by 
blocks, not by procedures. 



8600 2003-403 



7-17 



Compiler Controls 



Example 

BEGIN [SEGMENT=OUTERBLOCK, SEPC0MPLEVEL=5] 

PROCEDURE P(X); 
VALUE X; REAL X; 
BEGIN 

[UNSAFE (MEMORY, WORD) ,SEGMENT=5,C0NTR0LSTATE] 
END P; 

END. 

The following keywords are recognized as directives to the compiler. 

ASDSPACE 

The <integer> specifies the number of ASDs to be allocated in addition to the preallocated 
data and code segments and reserved ASD slots. Additional ASDs are necessary for any 
program that contains arrays. The default number of additional ASDs allocated is 0 (zero). 

BINDINFOLEVEL 

<bindinfolevel directivo 

— BINDINFOLEVEL — = — <integer> 1 

The BINDINFOLEVEL block directive specifies the highest lexical level for which 
BINDINFO is generated if the NOBINDINFO compiler directive is not set. At lexical levels 
higher than the specified <integer>, only external items, outputmessage arrays, and 
module alternatives modify the local directories generated. Local directories are always 
generated for the outer block. 

CONTROLSTATE 

This directive can be used when the block must be run in control state. CONTROLSTATE 
is inherited by all nested nonprocedure blocks, except those explicitly specifying 
NORMALSTATE. It is not inherited by procedures, including in-line procedures. 

Explicit use of the CONTROLSTATE block directive causes the block to be a new 
environment, resulting in the usual limitations: a GO TO statement from outside the block 
cannot branch to a label within the block, and a GO TO statement to a label outside the 
block is considered a bad GO TO. All bad GO TO statements outside of a 
CONTROLSTATE block cause a loss of control, even when the statements are branching 
to another CONTROLSTATE block. 

If the CONTROLSTATE block directive is used, the code file is marked as nonexecutable 
and unsafe. 
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FIRSTFREEDOCELL 

FIRSTFREEDOCELL specifies the first location (displacement) at lexical level 0 that can 
be allocated freely by the compiler. Locations below the FIRSTFREEDOCELL are reserved 
and can be allocated by means of an address equation. 

The default value of FIRSTFREEDOCELL is 10 (decimal), and it cannot be assigned a value 
less than 10. FIRSTFREEDOCELL is valid only when the MCP compiler control option is 
TRUE and only in the outer block of the program. 

FIRSTSEGDESC 

FIRSTSEGDESC is valid only for the outer block of a program being compiled with the 
MCP compiler control option set to TRUE. FIRSTSEGDESC accepts a constant integer 
value. The <integer> is used as the D[0] location where allocation for segment descriptors 
is to begin (similar to the ALGOL SEGDESCABOVE compiler control option). 

When this directive is set, segment descriptors (except those declared by an explicit 
SEGMENT declaration) are placed at D[0] locations, starting at FIRSTSEGDESC and 
proceeding to higher addresses. All other items placed in the D[0] stack are allocated as 
usual, starting at FIRSTFREEDOCELL. 

If, in the course of compilation under this block directive, the allocation point for normal 
items (not segment descriptors) reaches the beginning of the segment descriptors, a 
warning is issued and all further D[0] allocation occurs above the area currently occupied 
by segment descriptors. 

The MAKEHOST/SEPCOMP facilities in NEWP preserve the allocation points from the 
host and continue allocation in the same way. The BINDER adds only segment descriptors 
to the D[0] location and always adds them to the end, or top. The BINDER also preserves 
the MAKEHOST information for the SEPCOMP of a bound host. 

FIRSTSEGDESC is designed to relieve crowding in the addressable portion of the D[0] 
stack, to allow adding new variables to the D[0] stack during a SEPCOMP, and to 
encourage breaking up of large MCP code segments to improve memory utilization. 

This block directive allows items that must be addressed from lexical levels higher than 1 
to be given stack addresses that are visible from those higher lexical levels, even if the 
items are added by a separate compilation. The value given for FIRSTSEGDESC should be 
high enough to allow some spare D[0] cells below the segment descriptors. No benefit 
results from using a value higher than 4096. 

INHERITSTATE 

INHERITSTATE is allowed only for in-line procedures. It specifies that each invocation of 
the in-line procedure should run in the CONTROLSTATE/NORMALSTATE environment of 
the invoking code. 
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INLINE 



INLINE specifies that the procedure is to be compiled as an in-line procedure. For more 
information, see "In-Line Procedures" in Section 3, "Declarations." 



MEMIMAGEBOUND 

MEMIMAGEBOUND specifies the maximum size allowed for the memory image of a 
stand-alone program. If the size of the memory image exceeds the size specified by the 
block directive, a syntax error is given. This block directive is allowed only for the outer 
block and can be used only if the compiler control option STANDALONE is set. If the 
MEMIMAGEBOUND block directive is not used, the maximum size allowed for a memory 
image is 8192 words. 



NORANGECHECK 

When this directive is used, dynamic range checking for scalar types and sets, which is 
done by default, is disabled in the block. Code is not emitted to check ranges at run time. 

Dynamic range checking can be enabled for a block nested within this block through the 
use of the block directive RANGECHECK. 

When the NORANGECHECK block directive is set, range checking code is not emitted for 
the DIGITS phrase of the REPLACE statement. You should verify that the <arithmetic 
expression> that provides the number of digits is in the range 0 through 24. In addition, no 
dynamic range checking is done for user-defined scalar types and sets. 



NORMALSTATE 

The block is run in normal state by default, unless nested in other blocks for which the 
CONTROLSTATE block directive is specified. Explicit use of the NORMALSTATE block 
directive causes the block to be a new environment, resulting in the usual limitations: a 
GO TO statement from outside the block cannot branch to a label within the block, and a 
GO TO statement to a label outside of the block is considered a bad GO TO. 
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PROTECTED 

PROTECTED is valid only for an EXCEPTION PROCEDURE and is not inherited. This 
block directive indicates that the EXCEPTION PROCEDURE is protected from an entire 
class of interruptions, when it is invoked automatically by the system. 

Interruptions from which the EXCEPTION PROCEDURE is protected include software 
interrupts, a DS system command, a STOP command, and stack stretching. You should be 
particularly aware of the system's inability to stretch the stack during execution of a 
protected EXCEPTION PROCEDURE. Use of this block directive makes the code file 
unsafe and nonexecutable. 

For more information about EXCEPTION PROCEDURES and the way in which they can 
be invoked, see "EXCEPTION PROCEDURE Declaration" in Section 3, "Declarations." 

RANGECHECK 

This block directive is used to enable dynamic range checking for scalar types and sets. 
Code is emitted to check ranges at run time. 

Dynamic range checking is done by default for scalar types and sets. The block directive 
RANGECHECK is necessary only to enable range checking within a block for which range 
checking has been disabled by the block directive NORANGECHECK. 

SAFE 

The compiler generates syntax errors for all UNSAFE constructs used in this block, except 
those enabled by subsequent UNSAFE specifications. Such syntax errors are generated by 
default, and this directive is necessary only to enable the unsafe feature checking within a 
block for which the checks have been disabled by the block directive UNSAFE. 

SEGMENT 

Segmentation information for the block can be specified by one of the following phrases: 

• SEGMENT 

Makes a new segment. 

• SEGMENT <procedure identifier 

Adds the code for this block to the segment that contains the specified procedure. The 
<procedure identifier must have appeared previously in a PROCEDURE declaration 
or a <forward procedure declaration>. 

• SEGMENT <segment identifier 

Adds the code for this block to the segment associated with this segment name. The 
<segment identifier must have appeared previously in a SEGMENT declaration. 

• SEGMENT <integer> 

Adds to the segment number <integer>. 
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SEGMENTLEVEL 

The SEGMENTLEVEL block directive specifies the highest lexical level at which 
procedure declarations cause the compiler to generate a separate code segment. At lexical 
levels higher than the specified <integer>, procedure declarations are compiled into the 
code segment of their containing block or procedure (unless overridden by a SEGMENT 
block directive). For example, SEGMENTLEVEL = 2 causes all procedures declared at or 
below lexical level 2 to be put in separate code segments; all procedures declared above 
level 2 are, by default, compiled into the same segment as the block or procedure in which 
they are declared. The default SEGMENTLEVEL is 15. 



SEPCOMPLEVEL 

The SEPCOMPLEVEL block directive is valid only when MAKEHOST or SEPCOMP is also 
set. This block directive specifies the highest lexical level at which information is 
collected for use during a SEPCOMP. When the MCP option is reset, the default 
SEPCOMPLEVEL is 2. When the MCP option is set, the default is 0 (zero). 

For more information about this block directive, refer to the Section 6, "Compiling NEWP 
Programs." 



STATSUMMARY 

The STATSUMMARY block directive causes the compiler to emit calls on the statistics 
procedures at the entry and exit of the block in which the directive appears. For more 
information, refer to "STATISTICS" earlier in this section. 

Compound statements that specify STATSUMMARY are treated as blocks, or new 
environments. 



<target option > 

This compiler control option can also be used as a block directive. The <target option> 
specifies the computer family for which the generated code is to be optimized. There is no 
code generated to verify that the machine on which the code is running is compatible with 
the code generated. 

Note: Use of this construct is considered safe as long as none of the families is 

incompatible with the compilation option. See the ALGOL Programming Reference 
Manual, Volume 1: Basic Implementation/or a description of the compiler control 
option. If this use is not considered safe, then UNSAFE(MACHINEOPS) must be 
in effect. Without the UNSAFE declaration, an error is issued. 
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UNSAFE 

UNSAFE specifies that certain potentially dangerous constructs can be used in the block. 
UNSAFE is inherited by nested blocks and procedures. Table 7-1 shows the keywords 
used to specify the particular type of unsafe constructs permitted. 



Table 7-1. Unsafe Constructs Permitted 



Keyword 


Unsafe Construct 


DESCRIPTOR 


Allows the DESCRIPTOR data type, DESCRIPTOR expressions, and 
DESCRIPTOR type transfer function. 


FORK 


Allows FORK statements and PROCESS statements. 


MAPHINFnP^ 
iviMomiNQwr o 


AllruA/e tho Fl OAT nntinn in tho RPPI APF ctatomtint onrl tha iico nf tho 
ttllUWo Lllc rLUMI (jpUUII III lllc r\r_r LttL/i— Mdlcl 1 Icl IL dllU lllc Ubc Ul Ulc 

intrinsics requiring MACHINEOPS, which are listed in "Intrinsics (UNSAFE)" in 
Section 8, "UNSAFE Mode." 


MEMORY 


Allows the MEMORY array intrinsic. 


MISC 


Allows address equations, NULL as a <procedure body>, <option list>s on 
WAIT and WAITANDRESET statements, the OVERWRITE option on the 
REPLACE statement, SAVE ARRAY declarations, extensions to the 
SETACTUALNAME function, and the following intrinsics: BUZZ, BUZZ47, 
DAWDLE, LEXLEVEL, and LEXOFFSET. 


REFERENCE 


Allows the REFERENCE TO intrinsic, VIA intrinsic, and AT intrinsic. 


REGISTERS 


Allows the REGISTERS intrinsic and the DLL intrinsic. 


UPLEVEL 


Allows up-level pointer assignments and up-level procedure reference 
assignments. 


WORD 


Allows the WORD data type, WORD type transfer function, POINTER(<word 
expression^, and TAG. 
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UNSAFE Mode 



Some constructs that are required in order to perform hardware-related functions are 
considered unsafe for general use. NEWP requires you to specify when and which unsafe 
constructs are to be used. You can make this specification on a block-by-block basis 
through the use of the UNSAFE block directive. For more information on block directives, 
see "Block Directives" in Section 7, "Compiler Controls." 

Declarations (UNSAFE) 

Two additional datatypes are available in UNSAFE mode: DESCRIPTOR and WORD. In 
addition, address equation, NULL procedures, SAVE arrays, and special uses of segment 
identifiers are allowed in UNSAFE mode. 

ACTIVATION Structure Block Reference Variables— Untyped 

Activation structure block reference variables can be declared as untyped if you use the 
UNSAFE(MISC) directive. You can assign values to untyped activations using the 
<activation type transfer> . You cannot use untyped activations to assign values to typed 
activations. 

Untyped activations can be passed as parameters to either typed or untyped activations. 
However, when passed to typed activations, the UNSAFE (MISC) directive is required on 
the block. 
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Address Equation 

<equation part> 

=identifier>- 



U7 

<address couple>- 



cunsigned integer>- 



<— INTRINSIC — ( — <installation> — , — <intrinsic> — ) — 1 
<address couple> 

— ( — <lexical level > — , — <displacement> — ) 



<lexical level> 

"T 



<unsigned integer>- 

* 



<displacement> 

— <unsigned integer>- 



<installation> 

— <unsigned integer> 1 

<intrinsic> 

— <unsigned integer> 1 

Explanation 

Address equation in NEWP is much more powerful than in ALGOL and is allowed only in 
UNSAFE(MISC) mode. In declarations of variables, procedures, and arrays, the identifier 
being declared can be followed by the <equation part>. Address equation to call-by-name 
parameters is not allowed. 

If you use the = <identifier> form of address equation, the item being declared is assigned 
the same address as the identifier following the equal sign. The identifier must have been 
declared previously and must have an associated stack address. If the identifier is 
followed by the + <unsigned integer> syntax, the item being declared is assigned to the 
address at the same lexical level as the specified identifier. However, the declared item 
has a displacement that is <unsigned integer> words higher in the stack; the unsigned 
integer must be in the range 1 through 15. 
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Note: If the identifier that specifies the address is a call-by-reference parameter, the 
identifier being declared is assigned the address of the formal parameter, not 
the actual parameter. 

You can use the <address couple> form of address equation to specify directly the lexical 
level and displacement to be assigned to the item being declared. If you specify the 
•clexical level> as a simple unsigned integer, the item is assigned an address at that lexical 
level; the unsigned integer specified must be less than or equal to the current lexical level. 
If you specify the lexical level with an asterisk (*), the item is assigned an address at the 
current lexical level. The < displacement determines the offset of the item within the 
specified lexical level. 

Note: Do not use the <address couploform of address equation for the 

TRANSLATETABLE, TRUTHSET, VALUE ARRAY, or OUTPUTMESSAGE ARRAY 
declarations. 

For non-MCP programs, the INTRINSIC form of address equation allows direct access to a 
stack cell containing an intrinsic descriptor for the appropriate intrinsic. If the intrinsic 
has already been referred to, the existing address is used. Otherwise, a new cell is 
allocated and initialized with the appropriate intrinsic descriptor. 

Note: Most uses of the EVENT declaration, other than those allowed by ALGOL, might 
be incompatible with a change to the format of events. For example, neither of 
the following is acceptable: 

• The use of a variable declared by address equation to an EVENT or an EVENT 
ARRAY, for example: 

EVENT E; DOUBLE D = E; D:=0; 

• The use of an EVENT or EVENT ARRAY declared by address equation. For 
example: 

DOUBLE D; EVENT E = D; CAUSE(E); 

For more information on EVENT declaration, see the ALGOL Programming Reference 
Manual, Volume 1: Basic Implementation. 

Examples 

BOOLEAN BCOUNTER = (3,92); 
ARRAY COUNTS = BCOUNTS [0] ; 
INTEGER PROCEDURE C0UNT0NE = (*,15) (P1.P2); 
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DESCRIPTOR Declaration 

<descriptor declaration> 

— DESCRIPTOR -L<descriptor i denti f i er>— ■ - 

I— <equation part: 



<descriptor identifier> 

— <i denti f i er> 1 

Explanation 

Variables of type DESCRIPTOR are used to store original or copy descriptors. Simple 
variables of type DESCRIPTOR are declared in a DESCRIPTOR declaration. Arrays, 
procedures, and formal parameters can also be specified as type DESCRIPTOR. All uses of 
type DESCRIPTOR require the block directive UNSAFE (DESCRIPTOR) . 

Before being assigned a value, descriptor variables contain the uninitialized operand 
value: all zeros with a tag of 6. If a descriptor variable is referenced while it is 
uninitialized, an INVALID OPERAND fault occurs. Descriptor variables are accessed with 
the LOAD (as opposed to the LODT) operator. When a descriptor is evaluated, copy-bit 
action occurs if the target is a data descriptor. 

The type transfer function DESCRIPTOR can be applied to both WORD variables and 
arrays. Implicit type transfers, or coercions, allow array references to be assigned from 
DESCRIPTOR values and DESCRIPTOR data types to be assigned from array references 
or arrays. The same coercions are applied between formal and actual parameters. WORDs 
and DESCRIPTORS are mutually coerced. 

An array or DESCRIPTOR can be passed by-value to a formal parameter of type 
DESCRIPTOR. In either case, a copy descriptor is passed, and the original descriptor 
cannot be modified through the formal parameter. 

If an array or DESCRIPTOR is passed by-reference to a formal parameter of type 
DESCRIPTOR, a reference to the one-word descriptor for the array (that is, a Stuffed 
Indirect Reference Word (SIRW) or indexed data descriptor to the descriptor) is passed. In 
this case, the descriptor itself is the object and can be modified directly. 

If an array is passed by-reference to a formal array parameter, the compiler ensures that 
the formal and actual parameters have the same number of dimensions and then passes a 
copy descriptor. 

For information on descriptor declarations, see "WORD Declaration," "DESCRIPTOR 
Expressions," and "Intrinsics (UNSAFE)" later in this section. 
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HARDLOCK and HARDLOCK ARRAY Declarations 

<hardlock declaration> 

— HARDLOCK -L<hardl ock identifier^ 



<hardlock identifier> 

— <i denti f i er> 



<hardlock array declaration> 

— HARDLOCK — ARRAY 

ri 



L-<hardlock array identifier— 1 — [ — <bound pair list> — ] 
<hardlock array identifier> 

— <i denti f i er> 



Explanation 

An identifier declared to be a <hardlock identifier or an element of a hardlock array is 
used to protect a shared resource in a CONTROLSTATE environment. 

The initial state of a hardlock is FREE. For a list of the possible states of a hardlock, see 
the "LOCKSTATUS Function" under "HARDLOCK Functions" later in this section. 

PROCEDURE Declaration 

<procedure declaration> 

PROCEDURE — procedure heading>— ; > 



L<nrocedure tvne>— I 



procedure type>- 

proce 
NULL 



■»— j— <procedure body> 



Explanation 

In UNSAFE (MISC) mode, a <procedure body> can be specified as NULL. The procedure 
being declared must be address-equated. A null procedure declaration defines a calling 
sequence, but has no associated code. Before calling such a procedure, a Program Control 
Word (PCW) or a reference to a PCW must be provided at the address-equated location. 
For information on procedure declarations, see "Address Equation" earlier in this section. 
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SAVE ARRAY Declaration 

<save array declaration 

— SAVE — <array decl aration> 1 

Explanation 

In UNSAFE (MISC) mode, arrays can be declared SAVE, which causes the compiler to 
mark the arrays so that they cannot be overlaid. 

For multi-dimensional save arrays, the last dimension is handled as a SAVE LONG array 
and it cannot exceed the maximum size of 65535 words. 

SEGMENT Declaration 

<segment declaration 

— SEGMENT > 

r< » 1 

■»— <segment identifier— . ■— . ■— 1 — | 

^segment equate^ <— <segment MPCWSDI>— ' 

<segment equate> 

— = — <D0 address couple> 1 

<D0 address couple> 

— ( — 0 — , — <D0 displacement — ) 1 

<D0 displacement> 

— <unsigned integer> 1 

<segment MPCWSDI> 

— [ — MPCWSDI — = — oddress couple>— ] 1 
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Explanation 

In UNSAFE mode, segment identifiers can be used in address equations. For more 
information, refer to "Address Equation" earlier in this section. In addition, a <segment 
identifier can be address-equated itself, but only to a literal <address couple> with 
lexical level 0 and displacement less than the FIRSTFREEDOCELL. 

The <segment MPCWSDI> construct can be used to specify the Segment Dictionary Index 
(SDI) value used for Make Program Control Word (MPCW) operators that are generated 
during stack building code for the <segment identifiers 

A <segment identifier can be used as the parameter to the LEXOFFSET intrinsic and as 
the <address primary> in the <type> AT<address primary> construct. For more 
information, see "Intrinsics (UNSAFE)" later in this section and "SEGMENT Declaration" 
in Section 3, "Declarations." 

Examples 

SEGMENT SEG1 = (0,1) % legal 

SEGA = (0,1000), % syntax error if 1000 is 

% above the FIRSTFREEDOCELL 
SEGB = (1,2), % syntax error because it's 

% not at lex level 0 
SEGC = REALID; % syntax error because it's 
% relative, not absolute, 
% address equation 
SEGMENT GETITGOINGJEG [MPCWSDI =(0,1)]; 
PROCEDURE GETITG0ING; 
BEGIN [C0NTR0LSTATE, UNSAFE (MEMORY), SEGMENT=GETITG0ING_SEG] 
END GETITG0ING; 
WORD WSEG1 = SEG1; % legal 
REALID:= LEXOFFSET(SEGl) ; 
W0RDID:= WORD AT SEG1; 
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WORD Declaration 



— WORD — L<word identifier^— , — i I 1 

I— <equation part>— ' 

Explanation 

Type WORD is used for transparent examination and manipulation of arbitrary bit 
patterns, including machine control words. A value of type WORD is treated as an entity 
with 48 bits of data plus tag information, with no additional type significance. When values 
of type WORD are evaluated, the exact bit pattern in memory is returned. No copy-bit 
action occurs if the word accessed is a descriptor, and the second word is undefined if the 
word is part of a double-precision operand. 

Simple variables of type WORD are declared in a WORD declaration. Arrays, procedures, 
and formal parameters can also be specified as type WORD. All uses of type WORD 
require the block directive UNSAFE (WORD). 

Variables of type WORD are stored with overwrite operators and are accessed with the 
LODT operator. For information related to WORD declaration, see "WORD Expressions" 
later in this section. 

Note: Most uses of the EVENT declaration, other than those allowed by ALGOL, might 
be incompatible with a change to the format of events. User programs should 
avoid the implicit coercion of an EVENT or EVENT ARRAY element to a WORD, 
whether by direct assignment or as an actual parameter passed to a formal 
parameter of type WORD. 
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Statements (UNSAFE) 

The FORK statement is available in UNSAFE mode. In addition, extensions to the 
PROCESS, REPLACE, and WAIT statements are allowed. 

FORK Statement 

<fork statement> 

— FORK — <procedure invocation statement> — [ > 

-*-<arithmetic expression> — , — arithmetic expression> — , > 

-*-<arithmetic expression>— . r- ] 1 

I— , — <pointer expression^ 

Explanation 

The FORK statement is used in the MCP to initiate independent runners. The <procedure 
invocation statement> specifies the procedure to be initiated and its actual parameter list. 

The parameters in brackets are passed to the MCP procedure FORKHANDLER, which 
interprets these parameters as the box number of the box in which the task is to run, the 
size of the stack in which the task is to run, the priority of the task, and if the last 
parameter is present, the name to be displayed in the system mix entry for the task. The 
name defaults to the <procedure identifier if the last parameter is omitted. Note that on 
an ASD system the box number is ignored. 

The FORK statement is allowed only in UNSAFE(FORK) mode, and when the MCP dollar 
option is set and the STANDALONE option is not. 

PROCESS Statement 

The PROCESS statement is implemented with the same syntax as in ALGOL. You cannot 
invoke in-line procedures with a PROCESS statement. 

The use of this construct requires the UNSAFE(FORK) block directive. In addition, unlike 
the ALGOL implementation, you must establish and maintain the necessary critical block 
linkages between the parent and any processed tasks. 
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REPLACE Statement 
OVERWRITE Option 

<unit count> 



— FOR — arithmetic expression>- 



- WORDS 

L OVERWRITE 



Explanation 

In NEWP, the OVERWRITE option of the REPLACE statement is allowed in 
UNSAFE(MISC) mode. OVERWRITE appears in place of the WORDS specification in the 
syntax for <unit count>. 

The default unit size for the <replace statement> is expressed in characters. WORDS and 
OVERWRITE both indicate units of one word. OVERWRITE also overrides memory 
protection (odd tags) on both the source and the destination and suppresses memory 
parity errors on any prior contents of the destination. 



FLOAT Option 

<transfer part> 

— FOR — <length>— WITH — <edit micros>- 



<length> 

— arithmetic expression>- 



<edit micros> 



t— INSERT — ( — <insert character> — ) 
L- FLOAT — <FL0AT parameters> 



<FLOAT parameters> 

— ( — <insert character> — , — <float character> — ) 



<float character> 

— <EBCDIC constant>- 
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Explanation 

In UNSAFE (MACHINEOPS) mode, the FLOAT option is allowed as an extension to the 
<transfer part> of the REPLACE statement. In contrast, INSERT does not require UNSAFE 
mode. The INSERT option is described in "REPLACE Statement" in Section 4, 
"Statements." 



Like INSERT, the FLOAT option replaces the leading zero character. In addition, <float 
character> is inserted in the destination string before the first nonzero character 
transferred from the source. If the source string consists of the number of zeros defined in 
the <length> construct, only that number of insert characters is transferred to the 
destination string. No characters are transferred if <length> is zero or less. 

The source and destination pointer expressions must denote 8-bit characters. 
Furthermore, the resulting destination string is undefined if the source string contains 
characters other than the EBCDIC digits 0 through 9. 

TRY Statement and Expression 

<try limited form> 

— [ — <error procedure>— i ■— ] > 

L- : PROTECTED - 1 

■»— i— <procedure invocation statement>— . 1 

!— <procedure reference statement> — < 

<try normal form> 

r* 1 

— I 1— <statement>— ELSE — <statement>— 1 

L [ — : PROTECTED — ] - 1 

<try arithmetic normal form> 

[ — : PROTECTED — ] 



i 1— <arithmetic expression>- 

L [ — • PRriTFrTFn — 1 -I 



r<- 



■»— ELSE — <arithmetic expression>- 
<try Boolean normal form> 

[ — : PROTECTED — ] 



i 1— <Boolean expression>- 

L r — • PRDTFrTFn — 1 —I 



■*— ELSE — <Boolean expression>- 
<try pointer normal form> 

[ — : PROTECTED — ] 

r< 

■»— I— ELSE — <pointer expression>- 



i 1— <pointer expression>- 

L r — ■ PROTFPTFn — 1 -I 
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Explanation 

In UNSAFE(MISC) mode, the :PROTECTED option is allowed for the TRY statement and 
expression. The :PROTECTED option provides additional protection against every type of 
fault, including Operator DSed (Just DSed), Parent Process Terminated, and P-DS by 
another stack. 

The :PROTECTED clause offers protection against any and all forms and causes of 
process termination, with no limitations. All exceptions and limitations described for TRY 
do not apply when PROTECTED is specified. 

Note that :PROTECTED can only be used in NEWP if UNSAFE(MISC) is authorized. 



Caution 

Because :PROTECTED offers complete and unconditional protection against all 
forms of process termination, it is vital that code invoked to handle errors be as 
fast and efficient as possible, and that the stack be expanded as little as possible. 
Otherwise severe consequences can result, including processes that cannot be 
discontinued or even total system failure. 
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WAIT and WAITANDRESET Statements 

<wait statement> 

WAIT 



~E WAITANDRESET -I L [ _< wa it option list>— ] -I 
( — <wait parameter list> — ) 



<wait option list> 



-/l\-r- DSABLE 

L NOTDSABLE — 
-/1\- INTERRUPTIBLE - 1 

Explanation 

In UNSAFE(MISC) mode, the WAIT and WAITANDRESET statements can include a <wait 
option list> to specify whether the waiting process can be terminated by a DS system 
command. In safe mode, the WAIT and WAITANDRESET statements can only include the 
INTERRUPTIBLE option from the <wait option list>. The INTERRUPTIBLE option 
specifies whether the wait can be terminated by the process that is receiving a signal. The 
following options can be included in the option list: 



• DSABLE: This option causes the process not to wait if it is already terminated by a DS 
system command and not to continue to wait if it is externally terminated by a DS 
system command while waiting. The value returned by the WAIT function (if it occurs 
in an arithmetic expression) is zero in either case. 

• NOTDSABLE: This option causes the process to wait even if it is or becomes 
terminated by a DS system command. 

• INTERRUPTIBLE: This option causes the wait to be broken when the process 
receives a signal. 

If an <option list> is not given, default values are assigned according to the type of 
process. System processes (D[0] and pseudo D[0] relative code) default to NOTDSABLE. 
User processes default to DSABLE if the processes are not already terminated by a DS 
system command. If the process has already been terminated by a DS command, it must 
wait. 
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Expressions and Functions (UNSAFE) 

The expressions and functions described in this section are allowed in UNSAFE mode. 

AT [REFERENCE] 

— <type> — AT — <address primary> 1 

<address primary> 

addressable identifier— . 1 

— <subscripted variable> 

— <array row> 



<type> 

— |- BOOLEAN ■ r 

— <connection block type identifier— 

- DESCRIPTOR 

- DOUBLE 

- EVENT 

- FILE 

- INTEGER 

- INTERLOCK 

- POINTER 

- REAL 

— <structure block type identifier — 

- TASK 

— <type identifier 

L- WORD 1 



Explanation 

The <type> AT <address primary> syntax allows the item at the location specified by the 
<address primary> to be referred to or assigned to as if it had been declared of the 
specified <type>. If the AT syntax is used in an expression, the item is retrieved from the 
location in the manner appropriate for a value of the target <type>. 

For example, if D is a variable of type DESCRIPTOR, the syntax WORD(D) causes D to be 
retrieved as a DESCRIPTOR, and copy-bit action is performed. The syntax WORD AT D, 
on the other hand, causes the item at D to be fetched as a WORD, and no copy-bit action is 
performed. The WORD AT <address primary> syntax is valid only in UNSAFE(WORD) 
mode. The DESCRIPTOR AT <address primary> syntax is valid only in 
UNSAFE(DESCRIPTOR) mode. 

Note that if the specified <address primary> is a formal parameter, the <type> AT 
<address primary> syntax references the actual parameter, not the reference (SIRW or 
indexed data descriptor) that was passed. 
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Note: Except within the event-handling routines of the MCP, programs should avoid 
the use of the EVENT AT <address primary> or the<type> AT <address primary> 
syntax where the <address primary > has type EVENT, EVENT ARRAY, 
REFERENCE, or REFERENCE ARRAY. 

Examples 

WORD W; 
DESCRIPTOR D; 
W:= WORD AT D; 



DESCRIPTOR [DESCRIPTOR] 



— DESCRIPTOR — ( -|-<word expression — r- ) 
I— <array designator^— ' 



Explanation 

DESCRIPTOR is a type transfer function that can be applied to a WORD expression or 
array. 



DESCRIPTOR Expressions 

<descriptor expression> 

— I — <simpl e descriptor expression 

I— conditional descriptor expression: 



<simple descriptor expression> 

— descriptor primary> 



<descriptor primary> 

descriptor variable>— . 

I— := — <descriptor expression>— 

— <descriptor function designator 

— ( — descriptor expression> — ) 

— descriptor case expression> 
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<descriptor case expression> 



— <case head> — ( — L <descriptor expression>— L- ) 



— <if clause> — descriptor expression> — ELSE > 

->-<descriptor expression> 1 

Explanation 

DESCRIPTOR expressions generate values of type DESCRIPTOR. UNSAFE intrinsic 
functions that return values of type DESCRIPTOR include DESCRIPTOR AT <address 
primary>, the DESCRIPTOR type transfer function, and DESCRIPTOR VIA <word 
primary>. Descriptor expressions are valid only in UNSAFE(DESCRIPTOR) mode. 

For information related to DESCRIPTOR expressions, see "DESCRIPTOR Declaration" 
and "Intrinsics (UNSAFE)" in this section. 



HARDLOCK Functions [ MISC, CONTROLSTATE ] 

HARDLOCK functions use hardlocks or hardlock array elements to protect a shared 
resource in a CONTROLSTATE environment. The use of these functions is similar to the 
use of INTERLOCK functions, except that a process does not give up its processor when 
contending for the lock. 

LOCK FUNCTION 

<lock function> 

— LOCK — ( — <hardlock designator — ) — . 1 — I 

L- [ — CONDITIONAL — ] - 1 

Explanation 

The <lock function> attempts to acquire the hardlock. If you use the LOCK function as a 
statement, the process is discontinued when the result is not 1 (successfully acquired). If 
the CONDITIONAL option is used, the caller cannot wait, and the lock succeeds only if the 
hardlock is FREE. 

The LOCK function is of type INTEGER and the following values can be returned: 
Value Meaning 

1 The hardlock was successfully acquired. 

2 The CONDITIONAL option was used and the hardlock was not FREE. 
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The following conditions cause various values to be returned: 

• If the hardlock has a state of FREE, it becomes LOCKEDJJNCONTENDED and a 
result of 1 is returned. 

• If the hardlock is LOCKEDJJNCONTENDED, it becomes LOCKED_CONTENDED 
and the caller is placed in the contender list. When the owner unlocks the hardlock 
and the caller is at the head of the contender list, a result of 1 is returned. 

Examples 

LOCK (UNITMASTER) ; 

LOCK (PHYSICALUNITLOCK[PU]) ; 

IF LOCK [CONDITIONAL] (DTDLOCK) NEQ 1 THEN 
GO IDIDNTGETIT; 



LOCKSTATUS FUNCTION 

<lockstatus function> 

— LOCKSTATUS — ( — <hardlock designator^— ) 1 

The <lockstatus function> returns the status of the specified hardlock. If the 
LOCKSTATUS function is used as a statement, a warning is issued at compile time, and no 
code is generated for the LOCKSTATUS. The LOCKSTATUS function is of type REAL, and 
the result has the following subfields: 

[47:24] Owner's process ID; 0 if none 

[23:22] Undefined 
[01:02] Current state: 

0 FREE 

1 LOCKEDJJNCONTENDED 

2 L0CKED_C0NTENDED 

The owner portion of the hardlock status can be compared to the task attribute 
STACKNUMBER and the function PROCESSID. 

Examples 

R := LOCKSTATUS (UNITABLOCK) ; 

OWNERSNR := LOCKSTATUS (MIRR0R_L0CK[MIT_INDEX] ) . [47 :24] ; 
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UNLOCK FUNCTION 

<unlock function> 

— UNLOCK — ( — <hardlock designator— ) 1 

The <unlock function> is used to relinquish a hardlock that was previously acquired by a 
LOCK function. UNLOCK can be used as a function. If UNLOCK is used as a statement, the 
process is discontinued when the result is not 1 (successfully unlocked). 

The UNLOCK function is of type INTEGER, and the following values can be returned: 

Value Meaning 

1 The hardlock was successfully unlocked. 

6 The hardlock has a state of FREE and therefore cannot be unlocked. 



The following conditions cause various values to be returned: 

• If the hardlock is FREE, the state is not changed and a result of 6 is returned. 

• If the hardlock is LOCKED_UNCONTENDED when this operation is performed, the 
state is changed to FREE and a result of 1 is returned. 

• If the hardlock is LOCKED_CONTENDED, a result of 1 is returned, and the hardlock 
is given to the first contender in the contender list. If only one contender is in the list, 
the state is changed to LOCKEDJJNCONTENDED; otherwise, it is not changed. 

Examples 

I := UNLOCK (MAINFRAMELOCK) ; 

UNLOCK (PHYSICALUNITLOCK[PU]); 
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INTERLOCK Functions 
LOCK FUNCTION 

<lock function> 

— LOCK — 1 1— ( — interlock designator > 

L- [ DSABLE ] - 1 

n : r ] 1 

<— , — <timeout>— 1 
<timeout> 

— <arithmetic expression 1 

Explanation 

In UNSAFE(MISC) mode, the LOCK function for interlocks can include the DSABLE 
option. If the interlock is locked, this option causes the process not to wait if it has already 
been terminated by a DS system command and not to continue to wait if it is externally 
terminated by a system command while waiting. The value returned by the LOCK function 
is zero in either case. 

REFERENCE TO [REFERENCE and WORD] 

— REFERENCE — TO — <primary> 1 

Explanation 

The REFERENCE TO function returns a WORD that is equivalent to the value that would 
be generated to access the <primary> construct if the primary were a call-by-reference 
parameter. For example, valid WORDs include an SIRW for simple data type, a data 
descriptor for array rows, and an indexed data descriptor for subscripted variables. The 
<primary> construct can be of any data type that NEWP allows to be passed as a call-by- 
reference parameter. 

Note: If the specified <primary> is a call-by -reference parameter, the REFERENCE 

TO <primary> syntax returns a reference to the actual parameter, not the formal 
parameter. For example, ifX is the actual parameter passed by reference to the 
formal parameter R, then REFERENCE TO R returns a reference to X.Most uses 
of the EVENT declaration, other than those allowed by ALGOL, might be 
incompatible with a change to the format of events. Except within the event 
handling routines of the MCP, programs should avoid the use of REFERENCE 
TO <address primary> syntax where the <address primary> has type EVENT, 
EVENT ARRAY, REFERENCE, REFERENCE ARRAY, or INTERLOCKS. 

Example 

WORD W; 
REAL A; 

(PREFERENCE TO A; 
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SETACTUALNAME Function 

<setactualname function> 



— SETACTUALNAME — ( 



^library entrypoint identifiers 

<array identifier 

<file identifier>- 



=formal procedure identifier 



-*-<pointer expressions — ) 



Explanation 

In UNSAFE(MISC), a <file identifier:^ an <array identifier>, or a procedure identifier that 
is a formal parameter can be used as an alternative to the <library entrypoint identifiers 
However, you must ensure that the file, array, or formal procedure is a library object. 



SIZE Function 

<size function> 



— SIZE — ( -r- 



-<array designators 

-<procedure reference array designators 



descriptor expressions- 
<word expressions 



Explanation 

In UNSAFE (WORD) and UNSAFE (DESCRIPTOR) a <word expression and a 
<descriptor expression> can be used with the <size functions The descriptor expression 
or word expression must evaluate to an unindexed, touched data descriptor. If the 
expression does not, a run-time error can result. 
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VIA [REFERENCE] 

— <type> — VIA — <word primary> 1 

— |— <procedure identifier^ VIA — <word primary> > 

L-<exception procedure identifier^ 



I— <actual parameter part: 



Explanation 

The syntax <type> VIA <word primary> is used to access the item referenced by <word 
primary> as if the item were a value of the specified <type>. The word primary is first 
evaluated as a value of type WORD; the resulting value is then used as a reference, which 
is evaluated as a value of the specified type. Refer to the AT expression for a description 
of <type>. The REFERENCE TO expression generates word primaries that are appropriate 
for use with the VIA constructs. 

The form <procedure identifier> VIA <word primary> applies to procedure invocation. 
The word primary is used as a reference to effect a procedure entry; the contents of word 
primary should result in an Indirect Reference Word (IRW) to a PCW for the desired code 
in the appropriate environment. All type checking and parameter matching is performed 
according to the declared procedure heading, but the address couple of the procedure is 
irrelevant. 

The use of the EVENT VIA <word primary> syntax should be avoided except within the 
event-handling routines of the MCP. 

Examples 

W:= WORD VIA M[I] 

T:= PROC VIA REFERENCE TO W (PARAM) 

MYGEORGE VIA WORDSPIB[SNR,SIRWTOPALACE] (WHY) 
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WORD Expressions 



<word expression> 



simple word expressions 



conditional word express 



i on> — I 



<simple word expression> 

— <word primary> 



<word primary> 



-<word variable> — 
-<variable>- 



<expression>- 



— <i ntri nsi c> 

( — <expression> — ) - 
<word case expression>- 



L<update symbol s>— | I— <partial word part>— 
L .TAG 



<expressi on>— i— <concatenati on>- 
L T 



TAG 



<word case expression> 



case head> — ( — L <word expression>— ) 



<conditional word expression> 

— <if clause> — <word expression> — ELSE — <word expression>- 
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Explanation 

WORD expressions are extremely general because almost any type is implicitly type- 
transferred, or coerced, to type WORD when a WORD expression is expected. While no 
operators are defined for type WORD, an expression of any other type, including types 
with defined operators (such as addition in arithmetic expressions), can be assigned to a 
word variable. 

The .TAG clause can be used in place of the <partial word part> or in place of the 
< concatenation;^ and refers to the tag bits of the operand. 

Although the result of any intrinsic can be assigned to a WORD variable, the following 
UNSAFE intrinsics specifically return values of type WORD: 

• WORD(<expression>) 

• WORD VTA <word primary> 

• REFERENCE TO <primary> 

• EVAL 

• MAKEPCW 

• MEMORY 

• WORD AT <address primary> 

Word expressions are valid only in UNSAFE(WORD) mode. 
Note: Do not set TAG bits to a value of 2. 

For information related to WORD expressions, see "WORD Declaration" and "Intrinsics 
(UNSAFE)" in this section. 

Note: Most uses of the EVENT declaration, other than those allowed by ALGOL, might 
be incompatible with a change to the format of events. User programs should 
avoid the implicit coercion of an EVENT or EVENT ARRAY element to a WORD, 
whether by direct assignment or as an actual parameter passed to a formal 
parameter of type WORD. 
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WORD [WORD] 

— WORD — ( — <expression> — ) 1 

Explanation 

The WORD intrinsic performs a type transfer from the type of the <expression> to type 
WORD. Note that the type transfer is performed after the <expression> is fully evaluated. 
For example, the construct WORD(D), where D is of type DESCRIPTOR, evaluates D as a 
DESCRIPTOR and performs the copy-bit action before performing the type transfer to 
type WORD. 

Note: Do not set TAG bits to a value of 2. 

Intrinsics (UNSAFE) 

The intrinsics described in the following text are recognized only in UNSAFE mode; the 
UNSAFE category for each intrinsic is shown in brackets. 



Caution 

Intrinsics in the MACHINEOPS category are often available only on certain machine 
types. You should ensure that the operator generated by the intrinsic is supported 
on the machine on which the program is to run. 



In UNSAFE mode, a broader range of data types and expressions is allowed than is 
defined in safe mode. The following diagrams describe syntactic categories that are used 
to define valid parameters to the UNSAFE intrinsics: 
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addressable identifier> 



t— <array identifier r 

— <connection library identifier 

— <descriptor identifier 

— <event identifier 

— <exception procedure identifier 

— <file identifier 

— interlock identifier 

— <1 i brary i denti f i er 

— <output message array identifier 

— <pointer identifier 

— <procedure identifier 

— <procedure reference identifier 

— <procedure reference array identifier— 

— <segment identifier 

— <set variable identifier 

— <simple variable> 

— <structure block variable identifier — 

— <structure block array identifier 

— <structure block reference identifier— 

— <task identifier 

— <translatetable identifier 

— <truthset identifier 

— <type variable identifier 

— <value array identifier 

— <word identifier 
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ASDTABLE [MACHINEOPS] 

— ASDTABLE — [ — <integer expression — , > 

-*-<constant integer expression — ] 1 

Explanation 

ASDTABLE is an intrinsic that accesses the ASD table using the RASD (read) and WASD 
(write) operators. The first parameter indicates the ASD index, which is found in the lower 
20 bits of data and code descriptors. The second parameter is the ASD specifier, which 
must be a constant in the range 0 through 3 and must correspond to ASD1 through ASD4. 

Use of the ASD table is restricted in the following ways: 

• The first parameter must evaluate to an integer. 

• The second parameter must be an integer constant in the range of 0 through 3. In 
addition, if the reference is to the left of an assignment, a negative zero is valid and 
can be used to ensure the integrity of the unaltered bit when writing ASD1. 

• The ASD table cannot appear to the left of an embedded assignment. 

• The ASD control option must be set. 
Examples 

W:= ASDTABLE[K, 2] ; 

ASDTABLE[K,-0] := W; 

ASDTABLE[K,3] := * & 1 [47 : 1] & 0[43:1] ; 
ASDTABLE[K, 1] . [47:1] := 1; 
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BMASKSEARCH [MACHINEOPS] 

— BMASKSEARCH — ( — arithmetic expression— , > 

-*-<arithmetic expression — , — i— <array row> , > 

I— <subscripted variable^ 

-*-<arithmetic expression> — ) 1 

Explanation 

The integer function BMASKSEARCH is a bounded MASKSEARCH intrinsic that uses the 
BMS operator. This function is similar to MASKSEARCH, except that it requires a fourth 
argument to specify the word limit of the search. For more information on MASKSEARCH, 
see the ALGOL Programming Reference Manual, Volume 1: Basic Implementation. 

The fourth argument is the length, in words, to be searched within the domain specified by 
the third argument. The length must be less than or equal to 2**20-1. 

The result returned is the same as for MASKSEARCH. A failure result is returned under the 
following additional conditions: 

• If the search length is initially zero or negative. 

• If the search exhausts the search length. 

• If the search has examined word zero of the virtual segment or word zero of memory. 

BUZZ [MISC] 

— BUZZ — ( — <variable>— ) 1 

Explanation 

BUZZ is a REAL procedure that disables external interrupts and then uses the Read with 
Lock (RDLK) operator to exchange continually the following: 

• A value whose low-order bit (bit 0) is equal to 1 

• The current contents of the location specified by <variable> 

BUZZ continues exchanging until bit 0 of the value of the location is 0. This value is 
returned as the procedure value. BUZZ can be used only in CONTROLSTATE blocks. 

The semantics of BUZZ are affected by the values of the READLOCK and 
READLOCKTIMEOUT compiler control options. 

For information related to the BUZZ intrinsic, see "Compiler Control Options" in Section 7, 
"Compiler Controls." 
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BUZZ47 [MISC] 



BUZZ47 performs the same function as the BUZZ intrinsic, except that bit 47 of the 
parameter is tested and set instead of bit 0 (zero). BUZZ47 can be used only in 
CONTROLSTATE blocks. 



CALLIO [MACHINEOPS] 



— CALLIO — ( -|-<array row> ■ r- ) 

I— descriptor expression^ 



Explanation 

CALLIO is an untyped procedure that places the parameter on the top of the stack and 
executes the Communicate with Universal I/O (CUIO) operator. 

CHANGEEMULATIONSEGMENT [MACHINEOPS] 

— CHANGEEMULATIONSEGMENT — ( — <word expression— ) 1 



Explanation 

CHANGEEMULATIONSEGMENT is an untyped procedure that applies the Change 
Emulation Segment (CHES) operator to its parameter. This procedure changes the 
primary emulation code segment for the executing instructor processor. 

CHARACTER.RELATIONAL [MACHINEOPS] 

— CHARACTER_RELATIONAL — ( — <pointer expression— , > 

^pointer expres 
=string literal 



i— <pointer expression — , — arithmetic expression^ 

L-<strina literal>— i 

L- , — arithmetic expression> — 



CHARACTER_RELATIONAL is an integer intrinsic that compares the binary values of 
each corresponding character from the first argument and the second argument. The 
arithmetic expression specifies the number of characters to be compared. The possible 
result values are as follows: 

Value Meaning 

-1 For the first pair of unequal characters, the character from the first 

argument is strictly less than the character from the second argument. 

0 Each pair of characters is equal. 

1 For the first pair of unequal characters, the character from the first 
argument is strictly greater than the character from the second argument. 
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CHECKHASH [MACHINEOPS] 



— CHECKHASH — ( 



— i— <array row> 

I— <subscripted variables 



, — <length>— ) 



Explanation 

CHECKHASH generates the HASH operator. This procedure is of type REAL, with two 
parameters. The first parameter specifies an array row of type REAL. The second 
parameter is an integer. 

The result is defined by the following relation: 
hash[0] = 0 

hash[i] = (hash[i-l] EQV word [ 1] ). [46:48] 
Word[l] is the first word of the array row. 



— DAWDLE — ( — <integer constant> — ) 1 

Explanation 

DAWDLE is an untyped intrinsic that executes an arbitrary series of operators that do not 
access memory. The number of operators executed is directly proportional to the value of 
the <integer constants DAWDLE is used in the MCP to delay an operation without 
accessing memory. DAWDLE generates the Delay (DLAY) operator. 



Explanation 

DLL refers to the REGISTERS[LL] intrinsic, where LL is the current lexical level. This 
level is known by the compiler at compile time. 



DAWDLE [MISC] 



DLL [REGISTERS] 



— DLL 
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EVAL [MACHINEOPS] 



— EVAL — ( — i— <array identifier- 



<descriptor identifier- 
<event identifier- 



<exception procedure identifier- 
=file identifier 



-<interlock identifier 

-<output message array identifier- 
-<pointer identifier- 



— <procedure array identifier 

-<procedure identifier 

-<procedure reference array identifier- 

-<procedure reference identifier 

-<set variable identifier 

-<simple variable> 

-<task identifier 



-<translatetable identifier- 
-<truthset identifier- 



-<type variable identifier- 
lvalue array identifier — 
=word identifier- 



L- MEMORY — [<expression>] 



Explanation 

EVAL creates a reference to the location specified by the parameter and executes an 
Evaluate (EVAL) operator. EVAL is an intrinsic that returns a WORD data type containing 
the last reference in the chain (the reference that points to the final target). 

You cannot use the EVAL operator with call-by-name parameters. 

Note: The behavior of the EVAL operator will change on machines whose compiler 

target is encompassed by a target value of LEVEL 5. An indexed character data 
descriptor will no longer be treated differently from an indexed single or double 
data descriptor. That is, the indexed data descriptor will be returned as the 
result and not the reference to it. 



EXIT [MACHINEOPS] 

— EXIT 1 

Explanation 

EXIT generates the EXIT machine operator. The MCP procedure BLOCKEXIT is not called 
when an EXIT operator is executed. The EXIT intrinsic cannot be used in the body of an 
in-line procedure. 



8-30 



8600 2003-403 



UNSAFE Mode 



INTERRUPTCOUNTZERO [MACHINEOPS] 

— INTERRUPTCOUNTZERO 



Explanation 

INTERRUPTCOUNTZERO generates the Zero Interrupt Count (ZIC) operator. The 
interrupt counter of the processor (which is used to detect interrupt loops) is reset to 0 
(zero). If a Stack Overflow interrupt is pending, that interrupt is generated. 



LEXLEVEL [MISC] 



— LEXLEVEL — ( — i— <addressabl e identifier — r- 
I — <set variable identifier^— ' 



Explanation 

LEXLEVEL is an integer-valued procedure that returns the lexical level of the specified 
addressable identifiers For example, if X is declared at location (1,9), then 
LEXLEVEL(X) returns the value 1. The lexical level is known to the compiler at compile 
time. 



LEXOFFSET [MISC] 



— LEXOFFSET — ( -r-<addressabl e identifier^ — r- 
I — <set variable identifier^ 



Explanation 

LEXOFFSET returns an integer that is the offset (displacement) of the specified 
addressable identifier relative to the Mark Stack Control Word (MSCW). For example, if 
X is declared at location (1,9), then LEXOFFSET(X) returns the value 9. The offset is 
known by the compiler at compile time. The addressable identifier must not reference 
an in-line procedure. 

You cannot use the LEXOFFSET operator with call-by-name parameters. 
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LISTLOOKUP [MACHINEOPS] 

— LISTLOOKUP — ( — arithmetic expression — , — <array row> — , > 

-*-<arithmetic expression> — ) 1 

Explanation 

The syntax and semantics of LISTLOOKUP in NEWP are similar to LISTLOOKUP in 
ALGOL except that the array must be present, the array must not be segmented, and the 
Linked List Lookup (LLLU) operator is used instead of an MCP call. 

LOADEVENT [MACHINEOPS] 

— LOADEVENT — ( — <event designator— ) 1 

Explanation 

LOADEVENT is a word procedure that creates a reference to the < event identifier > and 
applies a Load Protected Object Word (LPOW) operator to it. If the <event identifier is a 
formal parameter of a procedure, a LOAD operator is applied to the reference to <event 
identifier before the LPOW is applied. 

LOADNOCHECK [MACHINEOPS] 

— LOADNOCHECK — ( — <word expression— ) 1 

Explanation 

LOADNOCHECK is an untyped procedure that applies the Load No Check (LDNC) 
operator to its parameter. The LDNC operator is used to return FLC and SLC originals and 
soft scrub memory. 
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MAKEPCW [MACHINEOPS] 



— MAKEPCW — ( 



^procedure identifier^ 

<exception procedure identi tier- 
s'! abel identifier 



Explanation 

MAKEPCW returns a WORD value containing a hardware PCW that points to the code for 
the specified procedure or label. This PCW has the NCSF field set to 1 for control state 
procedures and for labels declared in control state environments. The operator MPCW is 
generated by this intrinsic. 

If you specify a <procedure identifier or an <exception procedure identifier;-, the 
identifier must not reference a procedure declared EXTERNAL, NULL, LIBRARY, BY 
CALLING, or INLINE. In addition, the procedure must not be declared FORWARD at the 
time of the MAKEPCW invocation. The MAKEPCW invocation cannot occur within the 
body of the procedure being passed as the parameter to MAKEPCW. 

If you specify a <label identifier>, the declaration of the label must not be more global 
than the beginning of the code segment in which the label is used as a MAKEPCW 
parameter. The generated PCW points to the actual label occurrence, rather than to any 
hidden label generated for optimizations of bad GO TO statements. 



MEMORY [MEMORY] 

Explanation 

MEMORY can be used only when the MCP compiler control option is set. MEMORY is an 
intrinsic WORD array identifier referencing a one-dimensional array that maps all of 
memory. MEMORY can be used anywhere that a WORD array identifier is valid; however, 
NEWP does not allow a character-oriented pointer to be assigned to the memory array. 
For example, the syntax POINTER(MEMORY[ 0],8) is invalid. The default character size 
for pointers to the MEMORY array is 0 (word), not 8 (EBCDIC) as it is for other arrays; 
that is, the syntax POINTER(MEMORY[I]) is synonymous with 
POINTER(MEMORY[I], 0) . 

When the compiler control option ASD is set, MEMORY access uses the Absolute Store 
Reference Word (ASRW) operator. This change builds the ASRW for stand-alone 
programs. 



MOVESTACK [MACHINEOPS] 

— MOVESTACK — ( — arithmetic expression> — ) 1 

Explanation 

MOVESTACK places the parameter on the top of the stack and performs the Move Stack 
(MVST) operator. The parameter is changed to an integer before use. 
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PAUSE [MACHINEOPS] 

— PAUSE -, 

I— ( — <expressionl> — , — <expression2> — ) 



Explanation 

PAUSE generates the IDLE machine operator. If the parameters are present, they are 
loaded onto the stack as the top and next-to-top items before the IDLE operator is 
executed, and these parameters are deleted afterward. 



POINTER [DESCRIPTOR or WORD] 



— POINTER — ( — i— descriptor expression— i— ) 
I— <word expression ' 



Explanation 

This form of the POINTER intrinsic performs a type transfer from type DESCRIPTOR or 
type WORD to type POINTER. 

Note: If the parameter is a subscripted descriptor or word array, POINTER generates 
a pointer to that array element instead of performing the typetransfer. For 
example, if DA is declared as an array of type DESCRIPTOR, the syntax 
POINTER(DA[0]) generates a pointer to array DA instead of type transferring 
element 0 of the array to type POINTER. 



READANDCLEAREXTERNALS [MACHINEOPS] 

— READANDCLEAREXTERNALS — ( — <identifier>— , — <p2>— ) 1 

Explanation 

READANDCLEAREXTERNALS is an untyped procedure that executes the Read External 
Interrupt Identification (RDID) operator. Both <identifier> and <p2> are <variable>s of 
type REAL. The interrupt literal of the highest priority external interrupt is assigned to 
<identifier>. The P2 parameter of the highest priority external interrupt is assigned to 
<p2>. The interrupt condition reported is reset. If no external interrupts are outstanding, 
both items are assigned the value 0 (zero). 
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READMEMORYCONTROL [MACHINEOPS] 

— READMEMORYCONTROL — ( — <f unction definition>— ) 1 

Explanation 

READMEMORYCONTROL returns a type REAL that contains the result of executing the 
Read External Memory Control (REMC) operator. The <function definition> must be of 
type REAL. 

READPROCESSORSTATE [MACHINEOPS] 

— READPROCESSORSTATE — ( — <status identifier^— ) 1 

Explanation 

READPROCESSORSTATE returns a type REAL that contains the result of executing the 
Read Internal Processor State (RIPS) operator. The <status identifier must be of type 
INTEGER and is the internal status identification for the processor. 

READTIMEOFDAY [MACHINEOPS] 

— READTIMEOFDAY 1 

Explanation 

READTIMEOFDAY returns an INTEGER that contains the result of executing the Read 
Time of Day (RTOD) operator. 

REGISTERS [REGISTERS] 

— REGISTERS — [ — <constant integer expression> — ] 1 

Explanation 

The REGISTERS intrinsic returns the contents of the processor register specified by the 
<constant integer expressions-. 
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RESUME [MACHINEOPS] 

— RESUME — ( — <expression> — ) 1 

Explanation 

The RESUME intrinsic generates the REXI machine operator, conditionally leaving the 
value of the <expression> on the top of the stack. Specific vectored hardware interrrupt 
procedures can use the RESUME intrinsic to resume the interrupted code stream. The 
MCP procedure BLOCKEXIT is not called when a RESUME operation is performed. The 
RESUME intrinsic cannot be used in the body of an in-line procedure. 



RETURN [MACHINEOPS] 

— RETURN — ( — <expression> — ) 1 

Explanation 

RETURN generates the RETN machine operator, leaving the value of the <expression> on 
the top of the stack. The MCP procedure BLOCKEXIT is not called when a RETURN is 
performed. The RETURN intrinsic cannot be used in the body of an in-line procedure. 



RETURNORIGINALS [MACHINEOPS] 

— RETURNORIGINALS — ( — <double_the_cache_size>— ) 
<double_the_cache_size> 

— <numeric constant> 



Explanation 

RETURNORIGINALS generates code that forces the processor to contain only copies of 
data in its cache and no originals. 



RUNNINGLIGHT [MACHINEOPS] 

— RUNNINGLIGHT 



Explanation 

RUNNINGLIGHT generates the Running Light (RUNI) operator. 
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SCALERIGHTS [MACHINEOPS] 

— SCALERIGHTS — ( — arithmetic expression — , > 

-*-<arithmetic expression> — , — arithmetic variable> — ) 1 

Explanation 

The SCALERIGHTS function is an integer intrinsic that takes three parameters. The first 
parameter is a single- or double-precision value to be scaled (V). The second parameter is 
the scale-factor (SF), which must be in the range 0 through 12. The third parameter is an 
output parameter. The function returns the following result as the integer procedure 
value: 

V DIV 10**SF 

The remainder of V DIV 10**SF is returned in packed decimal form, left-justified, in the 
third (output) parameter. 

Note: The SCALERIGHTS intrinsic is scheduled for deimplementation in a future 
release. 

SENDTOREQUESTOR [MACHINEOPS] 

— SENDTOREQUESTOR — ( — <f unction definition>— , — <data>— ) 1 

Explanation 

SENDTOREQUESTOR is an untyped intrinsic that applies the Send to External Processing 
Element (SEND) operator to the two parameters. Both parameters are of type REAL. 

The <function definition> has the following layout: 

[43:08] Function code 

[07:08] Source or destination routing 

[07:04] Destination requestor number 

[03:04] Address of link or MSM (B 7900 machines) 

SETTIMEOFDAY [MACHINEOPS] 

— SETTIMEOFDAY — ( — arithmetic expression> — ) 1 

Explanation 

SETTIMEOFDAY changes the parameter to an integer, places it on the top of the stack, 
and executes the Write Time of Day (WTOD) operator. 
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SHOW [MACHINEOPS] 

— SHOW — ( — <SH0W source>- ) 



<SHOW source> 



-<EBCDIC string constant- 



arithmetic expression> — FOR — arithmetic expressions 
1 — <EBCDIC pointer expression> 



Explanation 

SHOW is an untyped intrinsic that uses the Primitive Display (SHOW) operator to display 
text, without involving the Input/Output subsystem. 

If the SHOW invocation occurs in a CONTROLSTATE block and the program is not 
compiled with the STANDALONE option, the length of the <EBCDIC string constant> is 
restricted to 12 characters; a longer string in this context results in a syntax error. (The 
compiler enforces this restriction to prevent control-state code from incurring a presence- 
bit interrupt on an absent string-pool array.) 

The number of characters actually displayed is limited by the machine; any additional 
characters in the source are ignored. A system with no primitive display mechanism 
disregards the SHOW operator; if a display mechanism exists, it must accommodate at 
least 24 characters. Depending on the implementation, a SHOW statement can erase a 
previous SHOW display. The <SHOW source> cannot cross a page boundary in a paged 
array. 

The display mechanism can restrict the character set that can be displayed. At least the 
following characters and blank can be displayed: 

ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789, ./+-=() 

The token SHOW is recognized but not reserved; the SHOW statement cannot be used if 
you have declared the identifier SHOW. 
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Examples 

SH0W("MCP STARTING"); % 12 characters: valid anywhere 

SH0W("UTIL0ADER STARTING") ;% Not valid in CONTROLSTATE 

% except in STANDALONE program 

SH0W(0 FOR 0); % Erase previous SHOW display 

REPLACE P BY...; 

SH0W(P FOR L); 

SH0W(D0UBLE((IF WHOAMI > 9 THEN WHOAMI + 'A' -10 

ELSE WHOAMI + '0' 
) & 'PROC 1 [47:40] 
, 1 ALARM' 
) FOR 12); 

SIGNALPROCESSOR [MACHINEOPS] 

— SIGNALPROCESSOR — ( — <integer expression>— , > 

-*-<arithmetic expression> — ) 1 

Explanation 

SIGNALPROCESSOR is an integer intrinsic that uses the Signal Processor (SPES) operator 
to send a signal to a processing element. The first parameter supplies the signal type in the 
range 0 through 7. The second parameter is a bit vector of type REAL that specifies the set 
of potential receiver processing elements. For example, subport S of port P is in the set if 
bit [2*P+S:01] = 1. 

The possible result values are as follows: 
Value Meaning 

0 No exception; a receiver is to be signaled. 

3 None of the designated receiver ports were available. 

5 A receiver processing element was not in the sender partition. (This 

exception might not be noted by all systems.) 
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STACKNUMBER [MACHINEOPS] 

The intrinsic STACKNUMBER is no longer available. The intrinsic function PROCESSID 
should be used instead. For more information on the <processid function>, see the 
ALGOL Programming Reference Manual, Volume 1: Basic Implementation. 



STOP [MACHINEOPS] 



— STOP 

L (<expression>,<expression> — p ) —I 

I— ,<variable>,<variable> — ' 



Explanation 

STOP generates the Conditional Halt (HALT) operator. If the first two parameters are 
present, the two values are loaded onto the stack as the top and next-to-top items before 
the HALT operator is executed. If the third and fourth parameters are present, they are 
interpreted as addresses into which the top-of-stack values are to be stored following 
execution of the HALT operator. The third and fourth parameter addresses receive the 
first and second parameter values, respectively; these values might have been modified by 
a user while the machine was stopped. 



STOP77 [MACHINEOPS] 

Explanation 

The STOP77 intrinsic is similar to the STOP intrinsic except that the STOP operator is 
generated. 
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STRING.COMPARE [MACHINEOPS] 

— STRING_COMPARE — ( — <pointer expression 

^pointer express 
=string literal>- 



i— <pointer expression> — , — arithmetic expressions 

I— <strina 1 i teral > — . 

I— , — <arithmetic expression> — 



STRING_COMPARE is an integer intrinsic that compares the binary values of each 
corresponding character from the first argument and the second argument. The arithmetic 
expression specifies the number of characters to be compared. The comparison operation 
terminates when either the length is exhausted or a null character is encountered in either 
of the character sequences. The possible result values are as follows: 

Value Meaning 

-1 For the first pair of unequal characters, the character from the first 

argument is strictly less than the character from the second argument. 

0 Each pair of characters is equal. 

1 For the first pair of unequal characters, the character from the first 
argument is strictly greater than the character from the second 
argument. 
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STRING.COPY [MACHINEOPS] 



— STRING COPY — ( — <destination> 



source> 



string 1 i teral >- 



r 



) 

<destination> 

— <pointer expression>- 

<source> 

— <pointer expression>- 



=length> 



<arithmetic expression> 



<del imiter>— > 



<length> 

— arithmetic expression>- 
<delimiter> 

— arithmetic expression>- 



STRING_COPY is an integer intrinsic that copies characters from the source to the 
destination until either the length is exhausted or the delimiter character is encountered. 
If the length is not exhausted, the delimiter character is copied to the destination. The 
number of characters copied is returned. 



SUSPEND [MACHINEOPS] 

Explanation 

The SUSPEND intrinsic is similar to the PAUSE intrinsic except that the Pause Until 
Interrupt (PAUS) operator is generated. 



SYSTEMCONTROL [MACHINEOPS] 

— SYSTEMCONTROL — ( — arithmetic expression — , > 

->-<word expression — ) 1 



Explanation 

SYSTEMCONTROL is a REAL intrinsic that uses the CSCP operator to communicate with 
the System Control Subsystem (SCS). The SCS is the subsystem responsible for system 
initialization and maintenance. The <arithmetic expression> parameter is of type REAL 
and specifies a function to the SCS. The <word expression> parameter is of type WORD 
and provides a word of data. The result value is the response from the SCS. 
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TESTRASD [MACHINEOPS] 

— TESTRASD — ( — arithmetic expression — , — <integer expression: 
) 



Explanation 

TESTRASD is a word procedure that returns the result of executing the RASD Test 
(RAST) operator to the two parameters. The RAST operator is intended only for debug use 
on Level Gamma machines. 

TESTWASD [MACHINEOPS] 

— TESTWASD — ( — <word expression — , — <real expression — , > 

^-<integer expression — ) 1 



Explanation 

TESTWASD is an untyped procedure that applies the WASD Test (WAST) operator to the 
three parameters. The WAST operator is intended only for debug use on Level Gamma 
machines. 



TIMER [MACHINEOPS] 



— TIMER — ( — arithmetic expression — ) 



Explanation 

TIMER loads the parameter value onto the top of the stack and executes the Set Interval 
Timer (SINT) operator. The <arithmetic expression> defines the time value in 
microseconds. The default is 512; the maximum value is 2047. 
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UNPACK [MACHINEOPS] 

— UNPACK — ( — <desti nation pointer> — , — <source> — , — <length> > 

*- ) 1 

— <EBCDIC pointer> 1 



— <arithmetic expression>- 



— <arithmetic expression> 1 

UNPACK takes a source value that is in packed decimal form and converts it into a string 
of EBCDIC numeric characters in the <destination pointer> for a specified <length>. The 
source can be double or single precision. The length can be 0 to 24 characters. The 
destination pointer points to the beginning of the converted result. 

The UNPACK intrinsic can be used as a pointer-update function by assigning the result to 
a pointer variable. The pointer is adjusted to a position that is <length> + 1 characters 
beyond the initial destination pointer position. 

UNPACK generates the Unpack-Unsigned-Delete (UPUD) operator and the Unpack- 
Unsigned-Update (UPUU) operator. The DECIMALCONVERT function produces a packed 
decimal value that us suitable for use as the source of an UNPACK. 
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VECTOR INTRINSICS [MACHINEOPS] 



The following constructs apply to the syntax diagrams for vector intrinsics: 
<vector> 



p<array row> r- 

I— subscripted variable>— ' 



<xvector> 



-i— <vector>— p 
I— <scalar>-^ 



<scalar> 

— arithmetic expression>- 



<length> 

— arithmetic expression>- 



<stride> 

— <arithmetic expression- 



Untyped Intrinsics That Act on Two Vectors 



( — <vector> 



VCPV - 
VCPVN -\ 
VCPVA 
VCPVS - 
VCPVD - 
VVPV — 
VVMV - 
VVMVN 
VVTV — 
VVOV — 
VVUV - 



-*-<stride> — , — <stride> — ) 



<xvector> 



=length> 



Explanation 

As is shown in Table 8-1, these untyped intrinsics act on two vectors. The first five 
intrinsics copy a function of B into A; the remaining six replace A by a function of A and B. 
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A is the vector defined by the first <vector> and first <stride>; B is the vector or scalar 
defined by the second <vector> or <xvector> and second <stride>. 

Table 8-1. Untyped Intrinsics: Two Vectors 



Intrinsic 


Operator 


Function 


VCPV 


CPV (Copy Vector) 


A:= B 


VCPVN 


CPVN (Copy Vector Negated) 


A:=-B 


VCPVA 


CPVA (Copy Vector Absolute) 


A:= 1 B 1 


VCPVS 


CPVS (Copy Vector Single) 


A:= single (B) 


VCPVD 


CPVD (Copy Vector Double) 


A:= double (B) 


WPV 


VPV (Vector Plus Vector) 


A:= A + B 


WMV 


VMV (Vector Minus Vector) 


A:= A-B 


WMVN 


VMVN (Vector Minus Vector Negated) 


A:= -A + B 


WTV 


VTV (Vector Times Vector) 


A:= A * B 


WOV 


VOV (Vector Over Vector) 


A:= A/B 


WUV 


VUV (Vector Under Vector) 


A:= B/A 



Untyped Intrinsics That Act on Two Vectors and a Scalar 

( — <vector> — , — <vector> — , — <length= 



WPS 



VVTS — 
- VVPVS - 
I— VVSPV - 1 



^-<stride> 



=stride> 



=scalar> 



) 



Explanation 

As shown Table 8-2, these untyped intrinsics act on two vectors and a scalar. 

Table 8-2. Untyped Intrinsics: Two Vectors and a Scalar 



Intrinsic 


Operator 


Function 


WPS 


VPS (Vector Plus Scalar) 


A:= B + S 


VVTS 


VTS (Vector Times Scalar) 


A:= B * S 


WPVS 


VPVS (Vector Plus Vector Times Scalar) 


A:= A + B * S 


VCSPV 


VSPV (Vector Times Scalar Plus Vector) 


A:= A * S + B 
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VCHEK Intrinsic 

— VCHEK — ( — <vector> — , — <length> — , — <stride> — , > 

-*-<expression> — ) 1 

Explanation 

VCHEK is a Boolean intrinsic that generates the Compute Check Hash (CHEK) operator to 
compute a result as a function of A and an initial single-precision <expression> H as 
follows: 

results H:= (H EQV A(i )). [46:48] 

VDOT and VDOTX Intrinsics 

— i— VDOT — i— ( — <vector> — , — <length> — , — <stride> — , > 

L VDOTX - 1 

-*-<expression> — ) 1 

Explanation 

VDOT is a REAL intrinsic that computes the dot (inner) product of two vectors. The value 
this intrinsic returns is the sum of the <expression> and the dot product. VDOTX is a 
similar double intrinsic. 

VFMX, VFMN, and VFMXA Intrinsics 

TVFMX — i— ( — <vector> — , — <length> — , — <stride> — , > 
VFMN — 
VFMXA - 1 

-*-<expression> — , — <expression>— . ) 1 

I— , — <variable>— ' 

Explanation 

These REAL intrinsics find the index of either the maximum (VFMX), minimum (VFMN), 
or maximum absolute (VFMXA) value within a vector. The first <expression> is returned 
as the intrinsic value if no vector element exceeds the second <expression>, which is an 
initial comparison value. If the <variable> is specified, it is set to the maximum (minimum 
or maximum absolute) value. 
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VGATH Intrinsic 

— VGATH — ( — <vector> — , — <vector> — , — <length> — , — <stride> — > 
, — <vector> — ) 1 

Explanation 

This untyped intrinsic accepts vector I with an implicit stride of +1 in place of the stride of 
B. The VGATH intrinsic generates the Gather (GATH) operator to compute the following: 

A(i):= B[I(i)] 

VPOLY Intrinsic 

— VPOLY — ( — <vector> — , — <xvector> — , — <length> — , — <stride>— > 
, — <stride> — , — <expression> — ) 1 

Explanation 

VPOLY is a REAL or DOUBLE intrinsic that generates the Polynomial Recurrence (POLY) 
operator to compute a result as a function of A, B, and an initial <expression> Z as 
follows: 

result:^ Z: = A(i) + B(i) * Z 



VSCAT Intrinsic 



— VSCAT — ( — <vector> — , — <xvector> — , — <length> — , — <vector>^ 
, — <stride> — ) 1 



Explanation 

This untyped intrinsic accepts vector I with an implicit stride of +1 in place of the stride of 
A. The VSCAT intrinsic generates the Scatter (SCAT) operator to compute the following: 

A[I(i)]:= B(i) 
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VSEQ Intrinsic 



— VSEQ — ( — <vector> — , — <xvector> — , — <length> — , — <stride> 
, — <stride> — , — <expression> — ) 



Explanation 

VSEQ is an untyped intrinsic that generates the Sequential Occurrence (SEQ) operator to 
compute A as a function of B and an initial <expression> Z as follows: 



A(i):= Z + B(i) 

VSUM and VSUMA Intrinsics 



— i— VSUM — i— ( — <vector> — , — <length> — , — <stride> — , 
L- VSUMA - 1 

<expression> — ) 



Explanation 

These REAL or DOUBLE intrinsics compute the sum of the elements of a vector. The type 
of the result (REAL or DOUBLE) is the same as the type of the <expression>, which 
represents the initial sum. The value of the result is the initial sum in addition to the sum 
of each element (or, for VSUMA, the absolute value of each element) of the vector. 



VSUMW Intrinsic 



— VSUMW — ( — <vector> — , — <length> — , — <stride> 
^-<expression> — ) 



Explanation 

The VSUMW intrinsic computes the sum of the elements of the vector (single precision, 
treated as 48 bit integers) and the double precision <expression>. The FIRSTWORD and 
SECOND WORD of the result can be added together (as 48 bit integers with end around 
carry) to produce the desired sum. 
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WHATAMI [MACHINEOPS] 

— WHATAMI 1 

Explanation 

WHATAMI generates the Read Machine Identification (WATI) operator and returns a type 
DOUBLE containing information about the machine type. Specifically, bits [07:08] of the 
most significant word define the machine type. 

WHOAMI [MACHINEOPS] 

— WHOAMI 1 

Explanation 

WHOAMI is an integer intrinsic that returns the result of executing the Read Processor 
Identification (WHOI) operator. 

WRITEMEMORYCONTROL [MACHINEOPS] 

— WRITEMEMORYCONTROL — ( — <f unction definition>— , — <data>— ) 1 

Explanation 

WRITEMEMORYCONTROL is an untyped intrinsic that applies the Write External Memory 
Control (WEMC) operator to the two parameters. Both parameters are of type REAL. 

WRITEPROCESSORSTATE [MACHINEOPS] 

— WRITEPROCESSORSTATE — ( — <status identifier^— , — <data>— ) 1 

Explanation 

WRITEPROCESSORSTATE is an untyped intrinsic that applies the Write Internal 
Processor State (WIPS) operator to the two parameters. The <status identifier> is of type 
INTEGER and is the internal status identification of the processor. The <data> construct 
is of type WORD and is the value to which the specified status is set. 
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ALGOL Features Not Implemented in 
NEWP 



This appendix lists the ALGOL features that are not implemented in NEWP. Some of these 
features have been replaced by NEWP features that perform the same function or a similar 
function, while others are considered inappropriate in the context of NEWP. 

General Features 

The following general ALGOL features are not available in NEWP: 

• COMPLEX type 

• STRING type 

• INTERRUPT declarations 

• OWN variables 

• SWITCH declarations 
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Specific Features 

The following specific items are not implemented in NEWP. Information about these items 
is available in the ALGOL Programming Reference Manual, Volume 1: Basic 
Implementation. 

The following tables include information about the NEWP features that can be used 
instead of the unsupported ALGOL features. 



Declarations 



Feature Not Available 

<array row equivalence> 

<complex declaration 

<direct array row 
equivalence> 

<dump declaration 

<format declaration> 

<forward interrupt 
declaration 

<forward switch label 
declaration 

<interrupt declaration> 

<list declaration 

<monitor declaration> 
<picture declaration> 

<string declaration 
<string array declaration> 



Alternative 

<array reference declaration> and <array 
reference assignment 



<array reference declaration> and <array 
reference assignment> 

TADS 

Format the data directly by using the various 
clauses of the REPLACE statement. 



Include the elements directly in the READ and 
WRITE statements. 

TADS 

Format the data directly using the various clauses 
of the REPLACE statement. 

EBCDIC arrays 

EBCDIC arrays 



A-2 



8600 2003-403 



ALGOL Features Not Implemented in NEWP 



Feature Not Available 

<switch file declaration 



Alternative 

Use a DEFINE with parameters to select the 
proper file instead of a switch file. For example: 



FILE Fl, F2, F3 (KIND = DISK); 
DEFINE SWITCH_FL [INX] = 

(CASE INX OF (Fl, F2, F3)) #; 

<switch format declaration Format the data directly using the various clauses 

of the REPLACE statement. The switching can be 
simulated with a define similar to the one shown 
under <switch file declarations 

<switch label declaration> Use a DEFINE with parameters similar to the one 

shown under <switch file declarations 

<switch list declaration Use a DEFINE with parameters similar to the one 

shown under <switch file declaration to select a 
READ or WRITE statement with the appropriate 
elements included directly. 
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Statements 

Feature Not Available 

<attach statement> 
<awaitopen statement> 
<changefile statements 



Alternative 



<checkpoint statement> 
<detach statement> 
<disable statement> 
<enable statement> 
<exchange statement> 

<fill statement> 

<merge statement> 

<multiple attribute 
assignment statement> 

<on statement> 



<removefile statement> 

<respond statement> 
<rewind statement> 
<space statement> 

<when statement> 



Open the file, change the TITLE attribute, and then 
close the file again with LOCK. Note that this process 
is slower than the <changefile statement> because of 
the need to open the file. 



Open both files, read the appropriate information into 
buffers, and then write the information out to the 
opposite files. 

< assignment statement> 



Use individual attribute assignment statements. 



Use an <on declaration> in place of the <on 
statements-. NEWP provides more fault names than 
ALGOL does. For more information, refer to the "ON 
Declaration" in Section 3, "Declarations." 

Use the CLOSE with PURGE statement. Note that if 
the file is not already open, it must be opened before 
the CLOSE can be done. 



<close option> RETAIN statement 
SEEK statement, for example: 

SEEK (<file designator>[SPACE arithmetic expr>]); 
WAIT statement 
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Expressions 

Feature Not Available Alternative 

<complex case 
expression> 

<complex expression> 

<complex function 
designator> 

<complex relation> 

<conditional complex 
expression> 

<conditional 
designational 
expression> 

<designational case 
expression> 

<dmin function> and These functions are unnecessary in NEWP because the 

<dmax function> MIN and MAX functions handle both single-precision 

and double-precision values. 

<dnormalize function> This function is unnecessary in NEWP because the 

NORMALIZE function accepts either a single or a 
double arithmetic expression as its parameter. 

<string function 
designator 
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The following ALGOL intrinsics are not directly supported in NEWP: 

• CHECKSUM, COMPLEX, CONJUGATE 

• DABS, DECIMAL, DELTA, DIMP, DNABS, DALPHA, DSCALELEFT, DSCALERIGHT, 
DSCALERIGHTT 

• FIRST 

• IMAG 

• LNGAMMA 

• SCALELEFT, SCALERIGHT, SCALERIGHTT 

The following ALGOL intrinsics are not directly supported in NEWP, but their 
functionality can be obtained by declaring GENERALSUPPORT as a library and importing 
the needed entry points: 

• ARCCOS, ARCSIN, ARCTAN, ARCTAN2, ATANH 

• CABS, CCOS, CEXP, CLN, COS, COSH, COTAN, CSIN, CSQT 

• DARCCOS, DARCSIN, DARCTAN, DARCTAN2, DCOS, DCOSH, DERF, DERFC, DEXP, 
DGAMMA, DLGAMMA, DLN, DLOG, DSIN, DSINH, DSQRT, DTAN, DTANH 

• ERF, ERFC, EXP 

• GAMMA 

• LN, LOG 

• RANDOM 

• SIN, SINH, SQRT 

• TAN, TANH 

The following <string function>s are not supported by NEWP, but the same functionality 
can be accomplished by using EBCDIC arrays or EBCDIC pointers or both: 

• DROP 

• HEAD 

• REPEAT 

• STRING, STRING4, STRING7, STRING8 

• TAIL, TAKE, TRANSLATE 
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Compiler Control Options 

The following ALGOL compiler control options are not implemented in NEWP: 

• AUTOBIND 

• BEGINSEGMENT, BIND, BINDER 

• CHECK 

• DONTBIND, DUMPINFO 

• ENDSEGMENT, EXTERNAL 

• FORMAT 

• GOTO 

• HOST 

• INITIALIZE, INTRINSICS 

• LEVEL, LIBRARY, LISTDELETED, LOADINFO 

• NOSTACKARRAYS, NOXREFLIST 

• OLDRESIZE, OPTIMIZE 

• PURGE 

• SEGDESCABOVE, SEQERR, STOP 

• USE 

• WRITEAFTER 

• XDECS, XREFS 
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Miscellaneous 

The following miscellaneous ALGOL features are not supported in NEWP: 

• Identifiers, numbers, and strings continued across card images. 

• LB and RB as synonyms for the square brackets ([ ]). 

• Multicharacter operators with embedded blanks. However, the Update Replacement 
operator (:=*) is allowed to have an arbitrary number of blanks between the equal sign 
(=) and the asterisk (*). 

• The KIND=READER file attribute for the compiler file CARD; CARD must be file- 
equated to a disk file. 

• Batch facility. 

• Compile-time facility. 

Product Interfaces 

The following products can interface with ALGOL but not with NEWP: 

• Advanced Data Dictionary System (ADDS) 

• Communications Management System (COMS) 

• Data Management System II (DMSII) 

• DMSII Transaction Processing System (TPS) 

• Screen Design Facility Plus (SDF Plus) 

• Semantic Information Manager (SIM) 
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Reserved Words 



A <reserved word> in NEWP has the same syntax as an identifier. The reserved words are 
divided into three types. 

Types of Reserved Words 

A reserved word of type 1 can never be declared as an identifier; that is, the reserved word 
has a predefined meaning that cannot be changed. For example, because DO is a type 1 
reserved word, the declaration is flagged with a syntax error as follows: 

ARRAY DO [0:999] 

A reserved word of type 2 can be redeclared as an identifier; the reserved word then loses 
its predefined meaning in the scope of that declaration. For example, because IN is a type 
2 reserved word, the following declaration is legal: 

FILE I N ( KI ND = READER) 

However, in the scope of the declaration, the following statement is flagged with a syntax 
error on the word IN: 

SCAN P WHILE IN ALPHA 

If a type 2 reserved word is used as a variable but is not declared as one, then the error 
message that results is not the expected UNDECLARED IDENTIFIER. Instead, the 
message might be the following: 

NO STATEMENT CAN START WITH THIS 
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A reserved word of type 3 is context-sensitive. This reserved word can be redeclared as an 
identifier, and if it is used where the syntax calls for that reserved word, it carries the 
predefined meaning. Otherwise, it carries the user-declared meaning. The different 
meanings for the type 3 reserved word TIMELIMIT are illustrated in the following 
example: 

BEGIN 

FILE F (KIND=REMOTE) ; 
REAL TIMELIMIT; 
ARRAY A [0:49] ; 

% IN THE NEXT STATEMENT, "TIMELIMIT" IS A REAL VARIABLE 
TIMELIMIT: = 4.5; 

% IN THE NEXT STATEMENT, "TIMELIMIT" IS A READ OPTION 
IF READ ( F [TIMELIMIT 60], 50, A) THEN 
% IN THE NEXT STATEMENT, "TIMELIMIT" IS A REAL VARIABLE 
TIMELIMIT:^ 60; 

END. 

All file attributes, direct array attributes, and mnemonics described in the File Attributes 
Programming Reference Manual are type 3 reserved words in NEWP. All task attributes 
and mnemonics described in the Task Attributes Programming Reference Manual are 
type 3 reserved words in NEWP. 
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Reserved Words List 

The following is an alphabetical list of reserved words for NEWP. The number in 
parentheses following each word indicates the type of the reserved word. For example, 
FOR (1) indicates that FOR is a type 1 reserved word. 

Note that the presence of a reserved word in this list does not necessarily imply that the 
feature is fully supported. Some words appear in this list because they are reserved for 
future implementation, or for consistency with ALGOL or the predecessor of NEWP 
(ESPOL). 



ACCEPT (2) 


ACTIVATION (1) 


ACTUALNAME (3) 


AFTER (3) 


ALL (3) 


ALTERNATIVE (2) 


AND (2) 


ANYFAULT (3) 


ANYTYPE (2) 


ARRAY (1) 


ARRAYS (3) 


ARROGATE (2) 


AS (3) 


ASCII (2) 


ASDSPACE (3) 


AT(1) 


ATEND (3) 


ATTRIBSEARCHER (2) 


AVAILABLE (3) 


AVAILATEND (3) 


BASE (3) 


BEFORE (3) 


BITS (2) 


BLOCK (3) 


BOOLEAN (1) 


BREAK (2) 


BUZZ (2) 


BUZZ47 (2) 


BY (2) 


BYFUNCTION (3) 


BYINITIATOR (3) 


BYTITLE (3) 


CALL (2) 


CALLING (3) 


CALLIO (2) 


CANCEL (2) 


CAND (2) 


CASE (1) 


CAT (2) 


CAUSE (2) 
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CAUSEANDRESET (2) 
CIMP (2) 
CODE (2) 
COMMENT (1) 
CONNECTION (2) 
CONTINUE (2) 
CONTROLSTATE (3) 
COR (2) 
DAWDLE (2) 
DEALLOCATE (2) 
DELAYSWAP (3) 
DESCRIPTOR (1) 
DIGITS (2) 
DISCARD (3) 
DIV (2) 

DONTWAIT (3) 

DREADMEMORYCONTROL (2) 
EBCDIC (2) 
EQL (2) 

ESTABLISH_ASDS (2) 
EXCEPTION (1) 
EXPONENTOVERFLOW (3) 
EXPORT (2) 
EXTERNAL (2) 
EXTERNALSUBROUTINE (2) 
FALSE (1) 



CHECKHASH (2) 
CLOSE (2) 
COMBINEPPBS (2) 
CONDITIONAL (3) 
CONSTANT (1) 
CONTROL (3) 
COPY (3) 
CRUNCH (3) 
DBS (3) 
DEFINE (1) 
DELINKLIBRARY (2) 
DETAIL (2) 
DIRECT (1) 
DISPLAY (2) 
DO (1) 
DOUBLE (1) 
DSABLE (3) 
EPILOG (1) 
EQV (2) 
EVENT (1) 
EXIT (2) 

EXPONENTUNDERFLOW (3) 
EXPORTLIBRARY (2) 
EXTERNALFUNCTION (2) 
FAILREGISTER (2) 
FI(1) 
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FILE (1) 

FIRSTFREEDOCELL (3) 
FIX (2) 
FOR (1) 
FORMAL (2) 
FORWARD (2) 
FREEZE (2) 
FUNCTIONNAME (3) 
GO (2) 

HARDWARE (3) 
HEYOU (2) 
IMP (2) 
IN (2) 

INITIALIZATION (1) 
INTEGER (1) 
INTERFACE (2) 
INTERLOCK (2) 
INTERRUPTCHANNEL (2) 
INTNAME (3) 
INVALID ADDRESS (3) 
INVALIDOP (3) 
IS (2) 

ISVALID (2) 
LBOUND (2) 
LIBACCESS (3) 
LIBLINKFAULT (3) 



FILES (3) 

FIRSTSEGDESC (3) 
FMMRREADLOCK (2) 
FORK (2) 
FORMAT (1) 
FREE (2) 
FROM (2) 
GEQ (2) 
GTR (2) 
HEX (2) 

IGNOREPARITY (2) 
IMPORTED (2) 
INHERITSTATE (3) 
INLINE (3) 

INTEGEROVERFLOW (3) 
INTERFACENAME (3) 
INTERLOCKOPS (3) 
INTERRUPTCOUNTZERO (2) 
INTRINSIC (2) 
INVALIDINDEX (3) 
INVALIDPROGRAMWORD (3) 
ISNT (2) 
LABEL (2) 
LEQ (2) 
LIBERATE (2) 
LIBPARAMETER (3) 
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LIBRARIES (3) 
LIMITED (1) 
LINKCLASS (3) 
LOCK (2) 
LONG (2) 
LSS (2) 
MCP (3) 
MEMORY (3) 
MEMORYPARITY (3) 
MESSAGESEARCHER (2) 
MLSACCEPT (2) 
MOD (2) 

MODULEEXPORT (2) 
MOVESTACK (2) 
NAME (2) 
NO (3) 

NORMALSTATE (3) 
NOT (2) 
NULL (2) 
OD (1) 
OFFER (3) 
OPEN (2) 
ORDERED (2) 
OVERWRITE (2) 
PAGE (3) 
PARITYFAIL1 (3) 



LIBRARY (2) 
LINE (3) 

LINKLIBRARY (2) 
LOCKSTATUS (2) 
LOOP (3) 
MACHINEOPS (3) 
MEMIMAGEBOUND (3) 
MEMORYFAIL1 (3) 
MEMORYPROTECT (3) 
MISC (3) 
MLSDISPLAY (2) 
MODULE (2) 
MODULEIMPORT (2) 
MUX (2) 
NEQ (2) 

NORANGECHECK (3) 
NOSWAP (3) 
NOTDSABLE (3) 
NUMERIC (2) 
OF (2) 
ON (2) 
OR (2) 

OUTPUTMESSAGE (1) 
PACK (3) 
PAGED (3) 
PAUSE (2) 
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PENDING (2) 
PICTURE (1) 
PRED (2) 

PRIVILEGEDINSTRUCTION (3) 
PROCESS (2) 
PROGRAMDUMP (2) 
PROLOG (2) 
PURGE (3) 
READ (2) 

READMEMORYCONTROL (2) 
READPROCESSORSTATE (2) 
REAL (1) 
REFERENCE (1) 
REPLACE (1) 
RESIZE (2) 
RETAIN (3) 
RETURN2 (2) 
ROW (3) 

RUNNINGLIGHT (2) 
SAVE (2) 
SCANIN (2) 
SCANPARITY (3) 
SEGMENT (2) 
SELECT (2) 
SEPCOMPLEVEL (3) 
SETACTUALNAME (2) 



PERMANENT (3) 
POINTER (1) 
PRrVATELIBRARIES (3) 
PROCEDURE (1) 
PROCURE (2) 

PROGRAMMEDOPERATOR (3) 
PROTECTED (3) 
RANGECHECK (3) 
READLOCK (2) 

READNANDCLEAREXTERNALS (2) 

READXMEMORYTABLE (2) 

RECEIVEFROMREQUESTOR (2) 

REGISTERS (3) 

RESETEVENT (2) 

RESUME (2) 

RETURN (2) 

RETURNORIGINALS (2) 

RUN (2) 

SAFE (3) 

SCAN (1) 

SCANOUT (2) 

SEEK (2) 

SEGMENTLEVEL (3) 
SENDTOREQUESTOR (2) 
SET (1) 
SETEVENT (2) 
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SETINHIBIT (2) 
SETTIMEOFDAY (2) 
SIBS (3) 
SINGLE (2) 
SORT (2) 
STACKER (3) 
STATION (3) 
STEP (2) 
STOP77 (2) 
STRINGPROTECT (3) 
SUBFILE (3) 
SUCC (2) 
SUSPEND (2) 
SYNCHRONIZE (3) 
SYSTEMLIB (3) 
TARGET (3) 
TEMPORARY (3) 
THIS (2) 
TIMELIMIT (3) 
TITLE (3) 
TODISK 

TRANSLATETABLE (2) 
TRUTHSET (2) 
UBOUND (2) 
UNLOCK (2) 
UNSAFE (3) 



SETLIMITS (2) 
SHOW (2) 

SIGNALPROCESSOR (2) 
SKIP (3) 
SPACE (3) 

STACKOVERFLOW (3) 
STATSUMMARY (3) 
STOP (2) 
STRING (1) 
STRUCTURE (1) 
SUBTYPE (2) 
SUPPLY (2) 
SWAPNOW (3) 
SYSTEMCONTROL (2) 
TAG (2) 
TASK (2) 
TESTWASD (2) 
THRU (1) 
TIMER (2) 
TO (2) 
TOPRINTER 
TRUE (1) 
TYPE (2) 
UNIVERSE (1) 
UNPACK (2) 
UNTIL (1) 
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UPLEVEL (3) 


URGENT (3) 


VALUE (1) 


VCPV (2) 


VCPVA (2) 


VCPVD (2) 


VCPVN (2) 


VCPVS (2) 


VGATH (2) 


VIA(l) 


VSCAT (2) 


VSEQ (2) 


WMV(2) 


WMVN (2) 


WOV (2) 


WPS (2) 


WPV (2) 


WPVS (2) 


WSPV (2) 


WTS (2) 


WTV(2) 


WUV(2) 


WAIT (2) 


WAITANDRESET (2) 


WHILE (1) 


WITH (2) 


WORD (2) 


WORDS (2) 


WRITE (2) 


WRITEMEMORYCONTROL (2) 


WRITEPROCESSORSTATE (2) 


WRITEXMEMORYTABLE (2) 


ZAP (2) 


ZERODIVIDE (3) 


ZIP (2) 
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Understanding Railroad Diagrams 



This appendix explains railroad diagrams, including the following concepts: 

• Paths of a railroad diagram 

• Constants and variables 

• Constraints 

The text describes the elements of the diagrams and provides examples. 

Railroad Diagram Concepts 

Railroad diagrams are diagrams that show you the standards for combining words and 
symbols into commands and statements. These diagrams consist of a series of paths that 
show the allowable structures of the command or statement. 

Paths 

Paths show the order in which the command or statement is constructed and are 
represented by horizontal and vertical lines. Many commands and statements have a 
number of options so the railroad diagram has a number of different paths you can take. 

The following example has three paths: 



— REMOVE 



SOURCE 
' — OBJECT 



The three paths in the previous example show the following three possible commands: 

• REMOVE 

• REMOVE SOURCE 

• REMOVE OBJECT 

A railroad diagram is as complex as a command or statement requires. Regardless of the 
level of complexity, all railroad diagrams are visual representations of commands and 
statements. 
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Railroad diagrams are intended to show 

• Mandatory items 

• User-selected items 

• Order in which the items must appear 

• Number of times an item can be repeated 

• Necessary punctuation 

Follow the railroad diagrams to understand the correct syntax for commands and 
statements. The diagrams serve as quick references to the commands and statements. 

The following table introduces the elements of a railroad diagram: 



Table C-l. Elements of a Railroad Diagram 



The diagram element... 


Indicates an item that... 


Constant 

Variable 

Constraint 


Must be entered in full or as a specific abbreviation 
Represents data 

Controls progression through the diagram path 
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Constants and Variables 

A constant is an item that must be entered as it appears in the diagram, either in full or as 
an allowable abbreviation. If a constant is partially boldfaced, you can abbreviate the 
constant by 

• Entering only the boldfaced letters 

• Entering the boldfaced letters plus any of the remaining letters 

If no part of the constant is boldfaced, the constant cannot be abbreviated. 

Constants are never enclosed in angle brackets (< >) and are in uppercase letters. 

A variable is an item that represents data. You can replace the variable with data that 
meets the requirements of the particular command or statement. When replacing a 
variable with data, you must follow the rules defined for the particular command or 
statement. 

In railroad diagrams, variables are enclosed in angle brackets. 

In the following example, BEGIN and END are constants, whereas <statement list> is a 
variable. The constant BEGIN can be abbreviated since it is partially boldfaced. 

— BEGIN — statement list>— END 1 

Valid abbreviations for BEGIN are 

• BE 

• BEG 

• BEGI 

Constraints 

Constraints are used in a railroad diagram to control progression through the diagram. 
Constraints consist of symbols and unique railroad diagram line paths. They include 

• Vertical bars 

• Percent signs 

• Right arrows 

• Required items 

• User-selected items 

• Loops 

• Bridges 

A description of each item follows. 
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Vertical Bar 



The vertical bar symbol (I) represents the end of a railroad diagram and indicates the 
command or statement can be followed by another command or statement. 



— SECONDWORD — ( — arithmetic expression— ) 



Percent Sign 

The percent sign (%) represents the end of a railroad diagram and indicates the command 
or statement must be on a line by itself. 

— STOP % 

Right Arrow 

The right arrow symbol (>) 

• Is used when the railroad diagram is too long to fit on one line and must continue on 
the next 

• Appears at the end of the first line, and again at the beginning of the next line 

— SCALERIGHT — ( — arithmetic expression — , > 

-*-<arithmetic expression — ) 1 



Required Item 

A required item can be 

• A constant 

• A variable 

• Punctuation 

If the path you are following contains a required item, you must enter the item in the 
command or statement; the required item cannot be omitted. 

A required item appears on a horizontal line as a single entry or with other items. Required 
items can also exist on horizontal lines within alternate paths, or nested (lower-level) 
diagrams. 
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In the following example, the word EVENT is a required constant and <identifier> is a 
required variable: 



EVENT — <identifier>- 



User-Selected Item 

A user-selected item can be 

• A constant 

• A variable 

• Punctuation 

User-selected items appear one below the other in a vertical list. You can choose any one 
of the items from the list. If the list also contains an empty path (solid line) above the 
other items, none of the choices are required. 

In the following railroad diagram, either the plus sign (+) or the minus sign (-) can be 
entered before the required variable <arithmetic expression;*, or the symbols can be 
disregarded because the diagram also contains an empty path. 

-<arithmetic expression 1 



Loop 



— + — 



A loop represents an item or a group of items that you can repeat. A loop can span all or 
part of a railroad diagram. It always consists of at least two horizontal lines, one below the 
other, connected on both sides by vertical lines. The top line is a right-to-left path that 
contains information about repeating the loop. 

Some loops include a return character. A return character is a character — often a comma 
(,) or semicolon (;) — that is required before each repetition of a loop. If no return 
character is included, the items must be separated by one or more spaces. 



cfield value>- 
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Bridge 



A loop can also include a bridge. A bridge is an integer enclosed in sloping lines (/ \) that 

• Shows the maximum number of times the loop can be repeated 

• Indicates the number of times you can cross that point in the diagram 

The bridge can precede both the contents of the loop and the return character (if any) on 
the upper line of the loop. 

Not all loops have bridges. Those that do not can be repeated any number of times until all 
valid entries have been used. 

In the first bridge example, you can enter LINKAGE or RUNTIME no more than two times. 
In the second bridge example, you can enter LINKAGE or RUNTIME no more than three 
times. 



-/2\-r- LINKAGE -r- 
L- RUNTIME - 1 



-/2V 



— U- LINKAGE n 1 

L- RUNTIME - 1 

In some bridges an asterisk (*) follows the number. The asterisk means that you must 
cross that point in the diagram at least once. The maximum number of times that you can 
cross that point is indicated by the number in the bridge. 



-i-/2*\- LINKAGE 
L- RUNTIME 



In the previous bridge example, you must enter LINKAGE at least once but no more than 
twice, and you can enter RUNTIME any number of times. 
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Following the Paths of a Railroad Diagram 

The paths of a railroad diagram lead you through the command or statement from 
beginning to end. Some railroad diagrams have only one path; others have several 
alternate paths that provide choices in the commands or statements. 

The following railroad diagram indicates only one path that requires the constant 
LINKAGE and the variable <linkage mnemonio: 



— LINKAGE — <linkage mnemonic>- 
Alternate paths are provided by 



• Loops 

• User-selected items 

• A combination of loops and user-selected items 

More complex railroad diagrams can consist of many alternate paths, or nested (lower- 
level) diagrams, that show a further level of detail. 



For example, the following railroad diagram consists of a top path and two alternate 
paths. The top path includes 



• An ampersand (&) 

• Constants that are user-selected items 

These constants are within a loop that can be repeated any number of times until all 
options have been selected. 

The first alternative path requires the ampersand and the required constant ADDRESS. 
The second alternative path requires the ampersand followed by the required constant 
ALTER and the required variable <new value>. 



— & 



TYPE - 
ASCII 
BCL - 



DECIMAL 
EBCDIC — | 
HEX 



OCTAL - 

ADDRESS 

ALTER — <new value>- 
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Railroad Diagram Examples with Sample Input 



The following examples show five railroad diagrams and possible command and statement 
constructions based on the paths of these diagrams. 

Example 1 
<lock statement> 

— LOCK — ( — <file identifier^ — ) 1 

Sample Input Explanation 

LOCK (FILE4) LOCK is a constant and cannot be altered. Because no part of the 



word is boldfaced, the entire word must be entered. 



The parentheses are required punctuation, and FILE4 is a sample 
file identifier. 



Example 2 



<open statement> 



— OPEN 



-<database name>- 



- INQUIRY - 
L- UPDATE — 1 



Sample Input 



Explanation 



OPEN DATABASE 1 



The constant OPEN is followed by the variable DATABASE 1, which 
is a database name. 



The railroad diagram shows two user-selected items, INQUIRY and 
UPDATE. However, because an empty path (solid line) is included, 
these entries are not required. 



OPEN INQUIRY 
DATABASE 1 



The constant OPEN is followed by the user-selected constant 
INQUIRY and the variable DATABASE 1. 



OPEN UPDATE 
DATABASE 1 



The constant OPEN is followed by the user-selected constant 
UPDATE and the variable DATABASE 1. 
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Example 3 

<generate statement> 



— GENERATE 



=subset> — 



-r- NULL — 
I— <subset>- 



- AND 
OR - 
I— + — 



=subset> 



Sample Input 

GENERATE Z = NULL 

GENERATE Z = X 
GENERATE Z = X AND B 



GENERATE Z = X + B 



Explanation 

The GENERATE constant is followed by the variable Z, an 
equal sign (=), and the user-selected constant NULL. 

The GENERATE constant is followed by the variable Z, an 
equal sign, and the user-selected variable X. 

The GENERATE constant is followed by the variable Z, an 
equal sign, the user-selected variable X, the AND command 
(from the list of user-selected items in the nested path), and 
a third variable, B. 

The GENERATE constant is followed by the variable Z, an 
equal sign, the user-selected variable X, the plus sign (from 
the list of user-selected items in the nested path), and a 
third variable, B. 



Example 4 

<entity reference declaration> 



— ENTITY REFERENCE 



— L<enti 



ty ref ID>— ( — <class ID>— ) 



Sample Input 

ENTITY REFERENCE ADVISOR1 
(INSTRUCTOR) 



ENTITY REFERENCE ADVISOR1 
(INSTRUCTOR), ADVISOR2 
(ASSTJNSTRUCTOR) 



Explanation 

The required item ENTITY REFERENCE is 
followed by the variable ADVISOR1 and the 
variable INSTRUCTOR. The parentheses are 
required. 

Because the diagram contains a loop, the 
pair of variables can be repeated any number 
of times. 
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Example 5 

— PS — MODIFY 



-i— <request number>- 
L < 



' — ALL 



request number> <request number>— ' 



IT 



EXCEPTIONS 



773 

773 



cfile attribute phrase>- 
=print modifier phrase>- 



Sample Input 

PS MODIFY 11159 



PS MODIFY 
11159,11160,11163 



Explanation 

The constants PS and MODIFY are followed by the variable 
11159, which is a request number. 

Because the diagram contains a loop, the variable 11159 
can be followed by a comma, the variable 11160, another 
comma, and the final variable 11163. 



PS MOD 11159-11161 
DESTINATION = "LP7" 



The constants PS and MODIFY are followed by the user- 
selected variables 11159-11161, which are request 
numbers, and the user-selected variable DESTINATION = 
"LP7", which is a file attribute phrase. Note that the 
constant MODIFY has been abbreviated to its minimum 
allowable form. 



PS MOD ALL EXCEPTIONS 



The constants PS and MODIFY are followed by the user- 
selected constants ALL and EXCEPTIONS. 
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A 

Absolute Store Reference Word (ASRW), 7-3 
Absolute Store Reference Word (ASRW) 

operator, 8-33 
ACCEPT statement, 4-1 
<accept statement>, 4-1 
<activation declarations-, 3-3 
<activation identifiers-, 4-6 
Activation Structure Block Reference 

Assignment, 4-6 
ACTIVATION Structure Block Reference 

Variables, 3-3 
untyped (UNSAFE), 8-1 
Activation Type Transfer Variable, 4-7 
<activation type transfers-, 4-7 
activation variables, 3-38 
<address couple>, 8-2 
address equation 

in INTRINSIC declarations, 3-18 
Address Equation Declaration (UNSAFE), 8-2 
<address primary>, 8-14 
addressable identifiers-, 8-24 
ALGOL 

compared with NEWP, 1-1 
alternative identifiers-, 3-26, 4-13 
alternatives-, 3-26 
anonymous set, 5-13 
<arithmetic constant declarations-, 3-8 
arithmetic expression, 5-4 
arithmetic function designator, 5-1, 5-8 
<arithmetic function designators-, 5-8 
arithmetic operator, 5-1 
<arithmetic operators-, 5-1 
<array classs-, 3-5 
ARRAY declaration, 3-5 
<array declarations-, 3-5 
ARRAY REFERENCE ASSIGNMENT 

statement, 4-7 
ARRAY REFERENCE declaration, 3-7 
<array reference declarations-, 3-7 
<array reference identifiers-, 3-7 
<array specifications-, 3-34 



<array types-, 3-36 

ARROGATE function, 5-17 

<arrogate functions-, 5-17 

< ASCII constants-, 2-2 

< ASCII numeric character >, 2-2 

< ASCII string characters-, 2-5 

< ASCII string constants-, 2-4 

ASD compiler control option, 7-3 

ASDSPACE block directive, 7-18 

ASDTABLE [MACHINEOPS] intrinsic 

(UNSAFE), 8-26 
ASRW, (See Absolute Store Reference Word 

(ASRW)) 
assignment compatibility, 3-54 
ASSIGNMENT statement, 4-5 
<assignment statements-, 4-5 
AT [REFERENCE] intrinsic (UNSAFE), 8-14 

B 

<base type identifiers-, 3-52 
basic symbols, 2-1 
<BCL characters-, 2-5 
<BCL string constants-, 2-5 
<binary characters-, 2-3 
<binary constants-, 2-3 
BINDINFOLEVEL block directive, 7-18 
block directives 

ASDSPACE, 7-18 

BINDINFOLEVEL, 7-18 

CONTROLSTATE, 7-18 

FIRSTFREEDOCELL, 7-19 

FIRSTSEGDESC, 7-19 

INHERITSTATE, 7-19 

INLINE, 7-20 

MEMIMAGEBOUND, 7-20 
NORANGECHECK, 7-20 
NORMALSTATE, 7-20 
PROTECTED, 7-21 
RANGECHECK, 7-21 
SAFE, 7-21 
SEGMENT, 7-21 
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SEGMENTLEVEL, 7-22 

SEPCOMPLEVEL, 7-22 

STATSUMMARY, 7-13, 7-22 

<target option>, 7-22 

UNSAFE, 7-23 
BMASKSEARCH [MACHINEOPS] intrinsic 

(UNSAFE), 8-27 
Boolean declaration, 3-1 
<Boolean declaration;-, 3-1 
Boolean expression, 5-5 

precedence in, 5-7 
Boolean function designator, 5-1, 5-8 
<Boolean function designator;-, 5-1, 5-8 
<Boolean library attribute specification>, 3-20 
Boolean primary, 5-1 
<Boolean primary>, 5-1 

<Boolean-valued library attribute name>, 3-20 

<bound pair>, 3-5 

BREAK function, 5-19 

•cbreak function>, 5-19 

BUZZ [MISC] intrinsic (UNSAFE), 8-27 

BUZZ47 [MISC] intrinsic (UNSAFE), 8-28 

c 

call-by-name parameter, 3-37 
call-by-reference parameter, 3-37 
call-by-value parameter, 3-37 
CALLIO [MACHINEOPS] intrinsic 

(UNSAFE), 8-28 
CARD input file, 6-5 
case expression, 5-1 
<case expression;-, 5-1 
<case head>, 4-9 
CASE statement, 4-1, 4-9 
<case statement>, 4-1 
CHANGEEMULATIONSEGMENT 

[MACHINEOPS] intrinsic 

(UNSAFE), 8-28 
character representation, 2-5 
CHARACTER_RELATIONAL [MACHINEOPS] 

intrinsic (UNSAFE), 8-28 
CHECKHASH [MACHINEOPS] intrinsic 

(UNSAFE), 8-29 
CLEAR compiler control option, 7-3 
CLOSE statement, 4-1 
<close statement>, 4-1 
coercion, 8-4 

Communicate with Universal I/O (CUIO) 

operator, 8-28 
compilation order, 3-25 



compiler control options 
$, 7-16 
ASD, 7-3 
CLEAR, 7-3 
INCLLIST, 7-3 
INSTALLATION, 7-4 
LIST, 7-4 
LIST1, 7-5 
LISTO, 7-4 
MAKEHOST, 7-5 
MCP, 7-5 
MERGE, 7-6 
MODSTRICT, 7-6 
NEW, 7-6 
NOCOUNT, 7-7 

not implemented in NEWP, A-7 
PROCREF, 7-7 
READLOCK, 7-7 
READLOCKTIMEOUT, 7-9 
SEPCOMP, 7-9 
SEPCOMPMERGE, 7-9 
SINGLE, 7-10 

STANDALONE, 7-3, 7-10, 7-11 

STATISTICS, 7-13 

TADS, 7-14 

UNDERLINE, 7-14 

VERSION, 7-15 

VOID, 7-15 

XREF, 7-16 

XREFFILES, 7-16 
COMPILETIME (20), 7-15 
COMPILETIME (21), 7-15 
COMPILETIME (22), 7-15 
Compute Check Hash (CHEK) operator, 8-47 
conditional descriptor expressions-, 8-15 
conditional expression, 5-2 
conditional expression;-, 5-2 
Conditional Halt (HALT) operator, 8-40 
conditional operator>, 5-5 
conditional word expression;-, 8-23 
connection block reference, 5-9 
CONNECTION BLOCK TYPE Declaration, 3-8 
CONSTANT declaration, 3-8 
constant declarations-, 3-8 
constant identifier;-, 3-8 
constant scalar type expression;-, 5-11 
constant value>, 3-8 
constants 

numeric, 2-2 

string, 2-4 
CONTROLSTATE block directive, 7-18 
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D 

<D0 address couple>, 8-7 
<D0 displacement>, 8-7 
DAWDLE [MISC] intrinsic (UNSAFE), 8-29 
DECIMALCONVERT function, 5-16 
<decimalconvert function>, 5-16 
declarations 
ARRAY, 3-5 

ARRAY REFERENCE, 3-7 
CONNECTION BLOCK TYPE, 3-8 
CONSTANT, 3-8 
EPILOG PROCEDURE, 3-10 
EXCEPTION PROCEDURE, 3-11 
EXCEPTION PROCEDURE 

FORWARD, 3-12 
EXPORT, 3-13 
INTRINSIC, 3-15 
LABEL, 3-19 
LIBRARY, 3-20 
MODULE, 3-21 
MODULE(old), 3-25 
not implemented in NEWP, A-2 
ON, 3-30 

OUTPUTMESSAGE ARRAY, 3-31 

PENDING PROCEDURE ACTUAL, 3-32 

POINTER, 3-33 

PROCEDURE, 3-34 

PROLOG PROCEDURE, 3-46 

SCALAR TYPE, 3-48 

SEGMENT, 3-46 

SET TYPE, 3-56 

SIMPLE VARIABLE, 3-47 

STRUCTURE BLOCK TYPE, 3-57 

STRUCTURE TYPE, 3-47 

STRUCTURE TYPE VARIABLE, 3-59 

SUPPLY, 3-59 

VALUE ARRAY, 3-61 

WITH, 3-61 
Delay (DLAY) operator, 8-29 
descendant types, 3-54 
DESCRIPTOR [DESCRIPTOR] intrinsic 

(UNSAFE), 8-15 
<descriptor case expressions-, 8-15 
DESCRIPTOR declaration (UNSAFE), 8-4 
<descriptor declaration;-, 8-4 
<descriptor expression>, 8-15 
DESCRIPTOR expressions (UNSAFE), 8-15 
<descriptor identifiers", 8-4 
<descriptor primary>, 8-15 
designational expression, 5-2 
<designational expressions-, 5-2 



<dimension specs>, 3-5 
dinteger function, 5-2 
<dinteger function>, 5-2 
DIRECT ARRAY declaration, 3-1 
<direct array declarations-, 3-1 
<displacement>, 8-2 

DLL [REGISTERS] intrinsic (UNSAFE), 8-29 

DOUBLE declaration, 3-1 

<double declarations-, 3-1 

<double_the_cache_size>, 8-36 

DSABLE option, 8-13 

dynamic procedure specification, 3-42 

E 

<EBCDIC constants 2-2 
<EBCDIC numeric character>, 2-2 
<EBCDIC string character>, 2-4 
<EBCDIC string constants 2-4 
<edit micros>, 4-12, 8-11 
enclosing module, 3-22 
<enumerated endpoint>, 3-53 
enumerated literal, 3-22 
<enumerated literal list>, 3-49 
<enumerated literal>, 3-49 
<enumerated range>, 3-53 
<enumerated type>, 3-49 
enumerated types, 3-49 

ordered, 3-50 

unordered, 3-50 
epilog procedure 

restrictions, 3-10 
EPILOG PROCEDURE declaration, 3-10 
<epilog procedure declaration;-, 3-10 
<epilog procedure identifiers-, 3-10 
<equation part>, 8-2 
EVAL [MACHINEOPS] intrinsic 

(UNSAFE), 8-30 
Evaluate (EVAL) operator, 8-30 
exception procedure 

restrictions, 3-11 
EXCEPTION PROCEDURE declaration, 3-11 
<exception procedure declarations-, 3-11 
EXCEPTION PROCEDURE FORWARD 

declaration, 3-12 
<exception procedure forward 

declarations-, 3-12 
<exception procedure identifiers-, 3-11 
EXIT [MACHINEOPS] intrinsic 

(UNSAFE), 8-30 
EXPORT declaration, 3-13 
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<export declarations-, 3-13 

<export list>, 3-25 

<export object specification>, 3-13 

<export options>, 3-13 

<exportable identifier>, 3-22 

<expression>, 5-2 

expressions 

arithmetic, 5-4 

Boolean, 5-5 

DESCRIPTOR (UNSAFE), 8-15 
function, 5-8 

not implemented in NEWP, A-5 
pointer, 5-10 
scalar type, 5-11 
set, 5-12 
string, 5-15 

WORD (UNSAFE), 8-22 

F 

fault handling, 3-30 
fault names, 3-30 
fault numbers, 3-30 

FIRSTFREEDOCELL block directive, 7-19 
FIRSTSEGDESC block directive, 7-19 
<float character>, 8-11 
FLOAT option (UNSAFE), 8-10 
<FLOAT parameters;-, 8-11 
FOR statement, 4-10 
<for statement>, 4-2, 4-10 
FORK statement (UNSAFE), 8-9 
<fork statement>, 8-9 
FORKHANDLER MCP procedure, 8-9 
<formal parameter list>, 3-34 
<formal parameter part>, 3-34 
FREEZE statement, 4-11 
<freeze statements 4-11 
FREEZE(MCP), 4-11 
full compilation, 6-2 
function expression, 5-2, 5-8 
<function expressions 5-2, 5-8 
functions 

ARROGATE, 5-17 

BREAK, 5-19 

DECIMALCONVERT, 5-16 
INTERLOCK, 5-17 
LOCK, 5-20 
LOCKSTATUS, 5-22 
LOWER BOUND, 5-24 
MAPPING, 5-25 
PACKDECIMAL, 5-24 



PREDECESSOR, 5-27 
SCALAR TYPE, 5-24 
SUCCESSOR, 5-27 
UNLOCK, 5-23 
UPPER BOUND, 5-28 

G 

Gather (GATH) operator, 8-48 
GO TO statement, 4-2 
<go to statements 4-2 

H 

HARDLOCK ARRAY declaration 

(UNSAFE), 8-5 
<hardlock array declarations 8-5 
HARDLOCK declaration (UNSAFE), 8-5 
<hardlock declarations 8-5 
<hexadecimal character >, 2-5 
<hexadecimal constant;., 2-3 
<hexadecimal string constant>, 2-5 
host compilation, 6-2 
HOST input file, 6-5 

I 

I/O statement, 4-2 
<I/0 statements 4-2 
identifier list>, 3-3 
implicit string concatenation, 3-31 
implicit type transfer, 8-4 
INCLLIST compiler control option, 7-3 
Indirect Reference Word (IRW), 8-21 
INHERITSTATE block directive, 7-19 
<initial part>, 4-10 
initialization procedures 3-26 
INLINE block directive, 6-7, 7-20 
in-line procedures, 3-39 
restrictions on, 3-39 
<insert character;., 4-12 
INSERT option, 4-12 

INSTALLATION compiler control option, 7-4 

installations 8-2 

integer constant identifier >, 3-53 

INTEGER declaration, 3-2 

integer declarations 3-2 

integer endpoint, 3-53 

integer endpoint>, 3-53 
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INTEGER function, 5-2 

<integer function>, 5-2 

<integer range>, 3-53 

<integer subtype endpoint>, 3-53 

<integer subtype range>, 3-53 

<interface body>, 3-22 

<interface declaration>, 3-22 

<interface identifier>, 3-22 

<interface>, 3-22 

INTERFACENAME, 4-12 

<interlock designator>, 5-17 

INTERLOCK function, 5-17 

INTERRUPTCOUNTZERO [MACHINEOPS] 

intrinsic (UNSAFE), 8-31 
INTERRUPTIBLE option, 8-13 
interruption protection, 7-21 
INTRINSIC declaration, 3-15 
•cintrinsic declaration^ 3-15 
intrinsic identifiers, 3-15 
< intrinsic >, 8-2 
intrinsics (UNSAFE), 8-24 
introduction to NEWP, 1-1 
IRW, {See Indirect Reference Word (IRW)) 
•citeration part>, 4-10 

L 

LABEL declaration, 3-19 
<label declaration;^ 3-19 
label designator, 5-2 
<label designator>, 5-2 
LABELS option, 7-13 
<length>, 8-11 

<level 2 procedure heading>, 1-2 
<level 2 procedure type>, 1-2 
<lex level >, 8-2 

LEXLEVEL [MISC] intrinsic (UNSAFE), 8-31 

LEXOFFSET [MISC] intrinsic (UNSAFE), 8-31 

<library attribute specs>, 3-20 

LIBRARY declaration, 3-20 

library declaration limit, 3-20 

<library declaration>, 3-20 

<linkage class>, 3-13 

Linked List Lookup (LLLU) operator, 8-32 
LIST compiler control option, 7-4 
LIST1 compiler control option, 7-5 
LISTLOOKUP [MACHINEOPS] intrinsic 

(UNSAFE), 8-32 
LISTLOOKUP function, 5-2 
<listlookup function>, 5-2 
LISTO compiler control option, 7-4 



Load Protected Object Word (LPOW) 

operator, 8-32 
LOADEVENT [MACHINEOPS] intrinsic 

(UNSAFE), 8-32 
LOADNOCHECK [MACHINEOPS] intrinsic 

(UNSAFE), 8-32 
LOCK function, 5-20 
<lock function>, 5-20 
LOCKSTATUS function, 5-22 
<lockstatus function>, 5-22 
LOWER BOUND function, 5-24 
<lower bound function>, 5-24 
<lower bound list>, 3-36 
<lower bound>, 3-5 
<lower bounds>, 3-7 

M 

Make Program Control Word (MPCW) 

operator, 8-7 
MAKEHOST compiler control option, 7-5 
MAKEPCW [MACHINEOPS] intrinsic 

(UNSAFE), 8-33 
MAPPING function, 5-25 
<mapping function>, 5-25 
Mark Stack Control Word (MSCW), 7-11, 8-31 
MCP compiler control option, 7-5 
MEMIMAGEBOUND block directive, 7-20 
MEMORY [MEMORY] intrinsic 

(UNSAFE), 8-33 
MERGE compiler control option, 7-6 
MLSaccept statement, 4-2 
<MLSaccept statement>, 4-2 
MODSTRICT compiler control option, 7-6 
<module body>, 3-21 
<module body> (old), 3-25 
MODULE declaration, 3-21 

restrictions, 3-22 
MODULE declaration (old), 3-25 
<module declaration;^ 3-21 
<module declaration> (old), 3-25 
module export, 3-22 
<module head>, 3-21 
<module head> (old), 3-25 
<module identifier>, 3-21 
<module identifier (old), 3-25 
module import, 3-23 
<moduleexport declaration>, 3-22 
<moduleimport declaration>, 3-22 
Move Stack (MVST) operator, 8-33 
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MOVESTACK [MACHINEOPS] intrinsic 

(UNSAFE), 8-33 
MSCW, {See Mark Stack Control Word 

(MSCW)) 
multidimensional array, 3-6 

N 

<name part>, 3-34 

nested module, 3-22 

NEW compiler control option, 7-6 

NEWP program essentials, 1-3 

NOBINDINFO option, 7-13 

NOCOUNT compiler control option, 7-7 

<nonnegative constant integer 

expression>, 3-49 
NORANGECHECK block directive, 7-20 
NORMALIZE function, 5-3 
<normalize function>, 5-3 
NORMALSTATE block directive, 7-20 
NOTDSABLE option, 8-13 
null value, 5-9 
<number list>, 4-9 
<number of digits>, 5-16 
numbers, 2-2 
numeric constants, 2-2 

0 

<octal character>, 2-3, 2-5 
<octal constant>, 2-3 
ON declaration, 3-30 
<on declaration>, 3-30 
ON statement, 4-2 
<on statement>, 4-2 
one-dimensional array, 3-6 
<open statement>, 4-2 
<operand to be converted>, 5-16 
<option expression>, 7-2 
< option primary >, 7-2 
<ordinal>, 5-12 

OUTPUTMESSAGE ARRAY declaration, 3-31 
"coutputmessage array declaration>, 3-31 
OVERWRITE option (UNSAFE), 8-10 



P 

PACKDECIMAL function, 5-24 
<packed-decimal result>, 5-16 
parameter passing, 3-37 
PAUSE [MACHINEOPS] intrinsic 

(UNSAFE), 8-34 
Pause Until Interrupt (PAUS) operator, 8-42 
PBITS option, 7-13 

PCW, {See Program Control Word (PCW)) 
PENDING PROCEDURE ACTUAL 

declaration, 3-32 
<pending procedure actual declaration;^ 3-32 
POINTER [DESCRIPTOR or WORD] intrinsic 

(UNSAFE), 8-34 
POINTER declaration, 3-33 

UPLEVEL option, 3-33 
<pointer declaration;^ 3-33 
pointer expression, 5-10 
Polynomial Recurrence (POLY) operator, 8-48 
POP LIST, 6-5 

precedence in Boolean expressions, 5-7 
PREDECESSOR function, 5-27 
<predecessor function>, 5-27 
Primitive Display (SHOW) operator, 8-38 
<procedure body>, 3-36 
PROCEDURE declaration, 3-34 
PROCEDURE declaration (UNSAFE), 8-4 
<procedure declaration;^ 3-34, 8-4 
<procedure heading>, 3-34 
PROCEDURE INVOCATION statement, 4-2 
<procedure invocation statement>, 4-2 
<procedure library attribute 

specification;-, 3-20 
PROCEDURE REFERENCE ARRAY 

declaration, 3-2 
<procedure reference array declaration;^ 3-2 
<procedure reference array 

specification^ 3-34 
<procedure specification;^ 3-34 
<procedure type>, 3-34 
procedure value, 3-42 
PROCESS statement (UNSAFE), 8-9 
PROCREF compiler control option, 7-7 
product interfaces 

not implemented in NEWP, A-8 
Program Control Word (PCW), 3-10, 3-11 
program interrupt, 5-9 
program unit, 1-2 

PROLOG PROCEDURE declaration, 3-46 
PROTECTED block directive, 7-21 
PROTECTED clause, 3-13 
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Q 

< quaternary character >, 2-3 
<quaternary constant>, 2-3 

R 

railroad diagrams, explanation of, C-l 
range checking, 3-55 
<range expressions 5-13 
RANGECHECK block directive, 7-21 
RCW, {See Return Control Word (RCW)) 
Read External Interrupt Identification (RDID) 

operator, 8-34 
Read External Memory Control (REMC) 

operator, 8-35 
Read Internal Processor State (RIPS) 

operator, 8-35 
Read Machine Identification (WATI) 

operator, 8-50 
Read Processor Identification (WHOI) 

operator, 8-50 
READ statement, 4-3 
<read statements 4-3 
Read Time of Day (RTOD) operator, 8-35 
Read with Lock (RDLK) operator, 8-27 
READANDCLEAREXTERNALS 

[MACHINEOPS] intrinsic 

(UNSAFE), 8-34 
READLOCK compiler control option, 7-7 

with BUZZ intrinsics, 7-7 
READLOCKTIMEOUT compiler control 

option, 7-9 

READMEMORYCONTROL [MACHINEOPS] 

intrinsic (UNSAFE), 8-35 
READPROCESSORSTATE [MACHINEOPS] 

intrinsic (UNSAFE), 8-35 
READTIMEOFDAY [MACHINEOPS] intrinsic 

(UNSAFE), 8-35 
REAL declaration, 3-2 
<real declarations 3-2 
REAL function, 5-3 
<real function>, 5-3 

REFERENCE TO [REFERENCE and WORD] 

intrinsic (UNSAFE), 8-19 
REGISTERS [REGISTERS] intrinsic 

(UNSAFE), 8-35 
•cremote module declaration>, 3-22 
REPLACE POINTER-VALUED ATTRIBUTE 

statement, 4-3 



<replace pointer-valued attribute 

statement>, 4-3 
REPLACE statement, 4-12 
REPLACE statement (UNSAFE), 8-10 
<replace statements 4-12 
reserved words, B-l 
RESET statement, 4-3 
<reset statements 4-3 
RESETEVENT statement, 4-3 
<resetevent statements 4-3 
RESIZE statement, 4-3 
<resize statements 4-3 
RESUME [MACHINEOPS] intrinsic 

(UNSAFE), 8-36 
RETURN [MACHINEOPS] intrinsic 

(UNSAFE), 8-36 
Return Control Word (RCW), 7-11 
RETURNORIGINALS [MACHINEOPS] 

intrinsic (UNSAFE), 8-36 
Running Light (RUNI) operator, 8-36 
RUNNINGLIGHT [MACHINEOPS] intrinsic 

(UNSAFE), 8-36 



s 

SAFE block directive, 7-21 
SAVE ARRAY declaration (UNSAFE), 8-5 
<save array declarations 8-5 
SCALAR TYPE declaration, 3-48 
<scalar type declarations 3-48 
scalar type expression, 5-11 
<scalar type expressions 5-11 
SCALAR TYPE function, 5-24 
scalar types 

in array references, 3-7 
SCALERIGHTS [MACHINEOPS] intrinsic 

(UNSAFE), 8-37 
Scatter (SCAT) operator, 8-48 
SCW, {See Software Control Word (SCW)) 
SEEK statement, 4-3 
<seek statements 4-3 
SEGMENT block directive, 7-21 
SEGMENT declaration, 3-46 
SEGMENT declaration (UNSAFE), 8-6 
<segment declarations 3-46, 8-6 
Segment Dictionary Index (SDI) value, 8-7 
<segment equates 8-7 
<segment identifiers 3-46 
<segment MPCWSDI>, 8-7 
segmentation, 1-3 

SEGMENTLEVEL block directive, 7-22 



8600 2003-403 



lndex-7 



Index 



SELECT statement, 4-13 
<select statement>, 4-13 
Send to External Processing Element (SEND) 

operator, 8-37 
SENDTOREQUESTOR [MACHINEOPS] 

intrinsic (UNSAFE), 8-37 
SEPCOMP 

background, 6-4 
compiling with, 6-3 
guidelines, 6-7 
performing a, 6-5 
SEPCOMP compiler control option, 7-9 
SEPCOMP MERGE, 6-9 
SEPCOMPLEVEL block directive, 6-4, 7-22 
SEPCOMPMERGE compiler control 

option, 6-2, 7-9 
Sequential Occurrence (SEQ) operator, 8-49 
set assignment, 4-8 
<set base type>, 3-56 
set expression, 5-12 
<set expressions-, 5-12 
<set identifier>, 3-56 
Set Interval Timer (SINT) operator, 8-43 
SET LIST, 6-5 
<set operator>, 5-12 
<set primary>, 5-12 
set relation, 5-7 
<set relation>, 5-5 
SET statement, 4-4 
<set statement>, 4-4 
SET structure type variable, 3-59 
SET TYPE declaration, 3-56 
<set type declarations", 3-56 
SETACTUALNAME function (UNSAFE), 8-20 
<setactualname function>, 8-20 
setevent statement, 4-4 
SETTIMEOFDAY [MACHINEOPS] intrinsic 

(UNSAFE), 8-37 
<short enumerated variable identifier>, 5-13 
<short scalar type expressions-, 5-13 
<short subtype variable identifier;-, 5-13 
SHOW [MACHINEOPS] intrinsic 

(UNSAFE), 8-38 
<SHOW source>, 8-38 
sibling module, 3-22 
Signal Processor (SPES) operator, 8-39 
SIGNALPROCESSOR [MACHINEOPS] 

intrinsic (UNSAFE), 8-39 
<simple descriptor expressions-, 8-15 
<simple scalar type expressions-, 5-11 
<simple set constructors-, 5-12 
<simple set expressions-, 5-12 
SIMPLE VARIABLE declaration, 3-47 



<simple variable declarations-, 3-47 
<simple word expressions-, 8-22 
SINGLE compiler control option, 7-10 
SIZE function, 5-3 
SIZE function (UNSAFE), 8-20 
<size functions-, 5-3, 8-20 
Software Control Word (SCW), 3-10, 3-12 
SOURCE input file, 6-5 
specifications-, 3-34 
<specifier>, 3-34 
STACK option, 7-12 
Stack Overflow interrupt, 8-31 
STANDALONE compiler control option, 7-3, 
7-10 
BETA, 7-11 

BETAINTERLEAVED, 7-11 
DELTA, 7-10 
statements 

ARRAY REFERENCE ASSIGNMENT, 4-7 
ASSIGNMENT, 4-5 
CASE, 4-9 
FOR, 4-10 

FORK (UNSAFE), 8-9 
FREEZE, 4-11 

not implemented in NEWP, A-4 

PROCESS (UNSAFE), 8-9 

REPLACE, 4-12 

SELECT, 4-13 

SET ASSIGNMENT, 4-8 

SWAP, 4-14 

TRY (UNSAFE), 8-11 

WAIT (UNSAFE), 8-13 

WAITANDRESET (UNSAFE), 8-13 
STATISTICS compiler control option, 7-13 
STATSUMMARY block directive, 7-13, 7-22 
STOP [MACHINEOPS] intrinsic 

(UNSAFE), 8-40 
STOP77 [MACHINEOPS] intrinsic 

(UNSAFE), 8-40 
string concatenation 

implicit, 3-31 
<string concatenation operators-, 5-15 
string constants, 2-4 
string expression, 5-15 
<string expressions-, 5-15 
<string primarys-, 5-15 

STRING_COMPARE [MACHINEOPS] intrinsic 

(UNSAFE), 8-41 
STRING_COPY [MACHINEOPS] intrinsic 

(UNSAFE), 8-42 
structure block reference, 5-9 
structure block reference assignment, 5-9 
STRUCTURE BLOCK TYPE Declaration, 3-57 
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STRUCTURE TYPE declaration, 3-47 
<structure type declaration;^ 3-47 
STRUCTURE TYPE VARIABLE 

declaration, 3-59 
<structure type variable declaration^ 3-59 
structures list>, 3-61 
<subtype>, 3-52 
subtypes, 3-52 
SUCCESSOR function, 5-27 
<successor function>, 5-27 
SUPPLY declaration, 3-59 
<supply declaration>, 3-59 
SUSPEND [MACHINEOPS] intrinsic 

(UNSAFE), 8-42 
SWAP statement, 4-14 
<swap statement>, 4-14 
SYSTEMCONTROL [MACHINEOPS] intrinsic 

(UNSAFE), 8-42 
SYSTEMLIB attribute 

in LIBRARY declarations, 3-20 



T 

TADS compiler control option, 7-14 
TAPE input file, 6-5 
<target option> block directive, 7-22 
TESTRASD [MACHINEOPS] intrinsic 

(UNSAFE), 8-43 
TESTWASD [MACHINEOPS] intrinsic 

(UNSAFE), 8-43 
<timeout>, 5-20 

TIMER [MACHINEOPS] intrinsic 

(UNSAFE), 8-43 
Top of Stack Control Word (TOSCW), 7-11 
TOSCW, {See Top of Stack Control Word 

(TOSCW)) 
<transfer part>, 8-11 

of <replace statement>, 4-12 
TRY expression, 5-3 
TRY statement (UNSAFE), 8-11 
<typed activation declaration:^ 3-3 
<typed activation designator;^ 3-61 
<typed activation expression;^ 3-61 
<typed activation specifier>, 3-61 

u 

UNDERLINE compiler control option, 7-14 
<unit count>, 8-10 
UNLOCK function, 5-23 



<unlock function>, 5-23 

UNPACK [MACHINEOPS] intrinsic, 8-44 

UNSAFE block directive, 7-23 

unsafe constructs permitted, 7-23 

<untyped activation declaration^ 3-3 

untyped intrinsics, 8-45 

UPLEVEL option 

POINTER declaration, 3-33 
UPPER BOUND function, 5-28 
<upper bound function>, 5-28 
<upper bound>, 3-5 
USERDATA function, 5-4 

V 

VALUE ARRAY declaration, 3-61 

<value array declaration;^ 3-61 

<variable ordinal>, 5-13 

<variable range expression>, 5-13 

<variable set constructor>, 5-13 

VCHEK intrinsic, 8-47 

VDOT intrinsic, 8-47 

VDOTX intrinsic, 8-47 

VECTOR INTRINSICS [MACHINEOPS] 

(UNSAFE), 8-45 
VERSION compiler control option, 7-15 
<version option>, 7-15 
VFMN intrinsic, 8-47 
VFMX intrinsic, 8-47 
VFMXA intrinsic, 8-47 
VGATH intrinsic, 8-48 

VIA [REFERENCE] intrinsic (UNSAFE), 8-21 
VOID compiler control option, 7-15 
<void option>, 7-15 
VPOLY intrinsic, 8-48 
VSCAT intrinsic, 8-48 
VSEQ intrinsic, 8-49 
VSUM intrinsic, 8-49 
VSUMA intrinsic, 8-49 

w 

WAIT statement, 4-4 
WAIT statement (UNSAFE), 8-13 
<wait statement>, 4-4 
WAITANDRESET statement, 4-4 
WAITANDRESET statement (UNSAFE), 8-13 
<waitandreset statement>, 4-4 
WHATAMI [MACHINEOPS] intrinsic 
(UNSAFE), 8-50 
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WHOAMI [MACHINEOPS] intrinsic 

(UNSAFE), 8-50 
WITH declaration, 3-3, 3-61 
<with declaration;^ 3-61 
WORD [WORD] intrinsic (UNSAFE), 8-24 
<word case expression;-, 8-23 
WORD declaration (UNSAFE), 8-7 
<word expression^ 8-22 
WORD expressions (UNSAFE), 8-22 
<word primary >, 8-22 
Write External Memory Control (WEMC) 

operator, 8-50 
Write Internal Processor State (WIPS) 

operator, 8-50 
WRITE statement, 4-4 
< write statement;-, 4-4 
Write Time of Day (WTOD) operator, 8-37 
WRITEMEMORYCONTROL [MACHINEOPS] 

intrinsic (UNSAFE), 8-50 
WRITEPROCESSORSTATE [MACHINEOPS] 

intrinsic (UNSAFE), 8-50 



X 

XREF compiler control option, 7-16 
XREFFILES compiler control option, 7-16 

z 

Zero Interrupt Count (ZIC) operator, 8-31 

Special Characters 

$ compiler control option, 7-16 

.LBOUND value, 3-6 
.TAG clause, 8-23 
.UBOUND value, 3-6 

<activation reference assignment;^ 4-6 
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